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ABSTRACT 


The  future  of  networking  technology  and  the  Internet  offer  a  great  deal  of 
promise.  The  potential  is  forthcoming  as  newer  hardware  technology  and  higher 
bandwidth  capable  protocols  are  designed  and  implemented.  This  thesis  investigates 
the  possibility  of  utilizing  existing  hardware  with  presently  available  software  to  create  a 
practical  communication  package  for  the  household.  The  household  communication 
package  or  home  communicator  is  the  network  core  of  the  household  linking  television, 
telephone,  and  web  browsing  capability  into  one  system.  The  home  communicator 
would  receive  an  incoming  television,  telephone  and  Internet  signal  via  optical  fiber  from 
a  single  service  provider. 

This  thesis  investigates  Linux  as  the  home  communicator  operating  system  with 
Internet  Protocol  version  6  as  the  network  protocol.  Linux  is  examined  for  its  proficiency 
at  being  a  capable  customer  oriented  operating  system.  Additional  Linux  compatible 
applications  are  studied  to  include  web  browsing,  e-mail,  chat  and  simple  text  editing. 
Finally,  IPv6  is  compared  to  IPv4  for  possible  enhancement  of  the  home  communicator. 
Individual  aspects  of  IPv6  are  investigated  for  additional  security  and  better  bandwidth. 
Linux  with  IPv6  was  found  to  be  an  acceptable  software  package  for  the  home 
communicator.  There  are  several  major  issues  preventing  an  easy  solution.  A  portion  of 
the  functionality  must  be  attained  through  the  Internet  Service  Provider. 
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I.  INTRODUCTION 


This  thesis  describes  the  study  of  a  new  type  of  household  communicator 
designed  to  work  in  a  high  bandwidth  network  environment.  This  is  based  on  the 
assumption  that  in  the  future  high  speed  optical  fiber  will  be  available  to  the  average 
household.  The  introduction  describes  the  evolution  of  networking  and  optical  fiber 
influence  on  the  past  and  present. 

A.  FUTURE  OPTICAL  FIBER  NETWORKS 

Information  Technology  is  the  objective  of  the  future.  Since  the  mid  1980's 
workstation  computers  have  continued  to  expand  into  the  work  and  home  environments. 
In  order  for  businesses  to  draw  on  the  growing  information  technology  networks  have 
been  created  to  tie  the  workstations  computers  together  fostering  an  environment  for 
their  employees  to  easily  share  applications  and  information.  No  longer  is  it  necessary 
to  physically  draw  up  a  brief  and  hand  it  to  the  boss.  It  now  can  be  electronically 
developed  within  minutes  and  delivered  within  seconds.  This  is  the  just  the  entryway  to 
the  power  possible  from  computers  and  computer  networking. 

Although  home  computing  has  not  kept  up  to  the  same  level  of  business 
computing  the  home  market  has  been  expanding  as  well.  Many  families  now  have  a 
network  of  computers  for  adult  and  child  interaction.  One  great  advantage  to  a  network 
environment  within  the  home  is  that  only  one  ISP  connection  allows  all  computers  to 
access  the  internet  at  the  same  time. 

The  actual  computer  is  just  one  facet  of  this  growing  information  technology, 
though.  In  order  for  the  computer  to  work  well  in  a  networked  environment  it  is  important 
to  have  bandwidth  and  speed  between  the  separate  workstations.  With  the  onset  of 
faster  more  capable  computer  processors  one  of  the  major  dilemmas  that  has  developed 
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is  increasing  the  bandwidth  and  speed  of  the  networked  connections  in  order  to  keep  up 
with  computer  speeds.  The  bandwidth  and  speed  of  a  network  connection  is  contingent 
upon  two  things,  the  medium  and  the  network  protocol  utilized.  Both  of  these  perform 
together  to  produce  the  actual  throughput  speeds  and  bandwidth  capability  actualized  in 
a  network. 

The  three  common  guided  transmission  mediums  are  twisted  pair,  coaxial  cable, 
and  optical  fiber.  The  general  information  for  bandwidth,  total  data  rate  capabilities,  and 
repeater  spacing  requirements  for  these  mediums  are  listed  in  Table  1-1.  The  repeater 
spacing  requirements  for  twisted  pair  and  coaxial  cable  compared  to  the  optical  fiber 
precludes  twisted  pair  and  coaxial  cable  as  good  procedurally  for  long  distance 
communications.  Twisted  pair,  CATV,  and  coaxial  cable  are  the  most  common  within 
the  office  building  environment  due  to  their  lower  hardware  and  installation  costs. 

Optical  fiber  has  been  used  most  often  for  long  distance  and  metropolitan  trunk  lines  due 
to  its  exceptional  bandwidth  capabilities  and  repeater  spacing  distance.  Wireless 
Transmission  is  not  within  the  scope  of  this  thesis. 


Transmission 

medium 

Data  Rate  Ranges 

Bandwidth 

Repeater  spacing 

Twisted  pair  / 
Category  3/4/5 

64  Kbps  -  1  Gbps* 

3.5  Kbps  - 100  MHz 

2  km 

Coaxial  cable 

40  -  500  Mbps 

1  -  500  MHz 

1  to  10  km** 

Optical  fiber 

2  Gbps  -  1  Tbps 

2  GHz  -  1  THz 

1 0  to  1 00  km 

*  Note:  data  rates  above  10  Mbps  are  limited  in  terms  of  the  number  of  devices  and 
geographic  scope  of  the  network. 


**  Note:  close  spacing  for  repeaters  is  required  for  higher  data  rates. 

Table  1-1  Point  -to  -point  transmission  characteristics  of  guided  media 

Up  through  the  mid  1990s  it  was  less  important  to  have  the  high  data  rate 
capability  down  to  the  workstation  computer.  Network  congestion  mostly  appeared  at 
the  higher  levels  of  the  networks  rather  than  at  the  workstation  computer  itself.  Packets 
of  information  transversing  the  internet  consisted  mostly  of  data  packets.  Today  it  is 
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more  common  to  transfer  large  imagery  files,  voice  files,  and  movie  files  in  addition  to 
the  normal  smaller  data  packets  between  computers  in  a  LAN  or  over  the  internet.  Also, 
Voice  over  IP  (VoIP)  and  video  teleconferencing  over  the  internet  are  much  more 
prevalent  today  than  5  years  ago.  VoIP  not  only  require  a  larger  bandwidth  to  the 
desktop  for  proper  utilization  but  they  also  add  timing  requirements  not  found  in  simple 
data  transfer.  It  is  important  that  live  voice  and  video  be  sent  within  a  relatively  short 
period  of  time  with  no  or  few  lost  packets.  Lowered  bandwidth  during  a  video 
teleconferencing  can  extremely  affect  video  quality.  Optical  fiber  holds  the  key  for 
greater  capabilities. 

In  the  past  ATM  (Asynchronous  Transfer  Mode)  technology  was  often  used  to 
realize  optical  fiber  bandwidth  potential.  ATM  afforded  good  throughput  for 
communications,  but  it  came  at  a  high  price.  The  added  speed  to  the  network  was  far 
outweighed  by  the  ATM  hardware  cost.  Also,  by  the  time  an  ATM  desktop  standard  was 
engineered  the  development  of  LAN  switching  technology  had  taken  hold.  The  time 
saved  in  switch  utilization  within  the  LAN  translated  into  increased  throughput  previously 
lost  to  non-ATM  LANs  such  as  Ethernet,  FDDI,  and  Token  Ring.  Hence,  ATM  was 
prevented  from  reaching  the  standard  desktop  [Ref.  1].  ATM  technology  settled 
comfortably  into  the  high  bandwidth  requirement  of  backbone  LAN  to  LAN  position. 

Ethernet  protocol  technology  has  increased  dramatically  in  the  past  few  years  to 
further  dissuade  the  use  of  ATM  in  networking  environments.  This  new  technology  has 
taken  the  Ethernet  speeds  up  to  the  Gigabit  level.  Gigabit  Ethernet  can  easily  make  use 
of  the  optical  fiber  medium  through  the  IEEE  802.3z  standard  with  1000BASE-SX  and 
1000BASE-LX  specifications  [Ref.  2].  In  a  Gigabit  Ethernet  network  the  interface 
equipment  to  the  optical  fiber  medium  is  more  expensive  than  standard  Ethernet 
technology,  but  the  extended  throughput  without  overall  network  redesign  required  with 


3 


ATM  is  inviting.  Also,  due  to  the  growing  technology  with  Ethernet  capability  Ethernet 
now  spans  all  communications  media  where  ATM  is  limited  to  optical  fiber. 

Optical  fiber  has  always  been  known  as  a  high  bandwidth,  low  error  rate  medium 
for  communications.  The  available  bandwidth  in  optical  fiber  is  approximately  50  THz.  A 
peak  electronic  speed  of  only  a  few  gigabits  per  second  has  previously  prevented 
utilization  of  optical  fiber's  inherent  higher  bandwidth  capabilities,  though.  Very  recently 
a  new  form  of  technology,  wavelength-division  multiplexing  (WDM),  further  extends  the 
practical  bandwidth  of  optical  fiber  in  communications  systems. 

WDM  networks  are  third-generation  technology  compared  to  non-fiber 
technology  utilizing  Ethernet  and  fiber  technology  utilizing  fiber  distributed  data  interface 
(FDDI)  or  ATM.  Optical  fiber  that  was  laid  years  ago  with  a  calculated  second- 
generation  bandwidth  cap  of  2  Gbps  now  can  be  employed  with  WDM  technology 
creating  a  considerably  greater  capacity  of  more  than  40  Gbps.  [Ref.  3]  WDM 
technology  uses  multiple  wavelengths  of  light  simultaneously  to  create  channels  that 
operate  independently  of  each  other  yet  within  the  same  physical  fiber.  Each  of  these 
channels  can  be  used  to  transmit  data  at  the  low  Gbps  rate. 

In  1996  researchers  at  Nippon  Telegraph  and  Telephone  (NTT)  demonstrated  a 
WDM  system  that  multiplexed  16  separate  channels  of  independent  6.3  Gbps  signals 
into  an  overall  400  Gbps  signal.  The  WDM  multiplexed  signal  was  amplified  and 
transmitted  over  a  100  km  optical  fiber  transmission  line.  At  the  other  end  this  400  Gbps 
signal  was  de-multiplexed  into  the  original  individual  16  channels  and  converted  to 
electrical  signals.  This  experiment  was  completed  within  a  controlled  environment,  yet 
that  does  not  preclude  the  chances  of  technology  soon  leading  us  to  this  capability 
within  the  existing  World  Wide  Web  atmosphere.  [Ref.  4] 

With  the  increased  utilization  of  optical  fiber  capabilities  it  is  obvious  the  next 
bottleneck  to  communications  flow  lies  in  the  electronic  buffer  requirement  at  each 
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network  hop.  Presently  existing  networks  require  electrical  processing  to  be  done  at 
every  node.  The  optical  fiber  technologies  thus  described  are  only  utilized  for  point-to- 
point  transmission.  It  is  anticipated  that  the  next  generation  will  utilize  more  photonic 
exchanges.  Future  photonic  networks  will  use  direct  optical  connections  without 
electrical  processing.  Also,  optical  switches  are  presently  being  developed  that  handle 
320  Gbps  [Ref.  4],  The  future  of  optical  fiber  within  the  networking  arena  is  highly 
favored. 

Probably  one  of  the  strongest  indications  that  optical  fiber  will  have  continued 
presence  and  growth  in  the  future  as  a  main  structure  of  internet  networking  is  the 
present  business  trend  to  utilize  fiber  within  and  between  the  major  industrial  countries 
of  the  world.  Denver  based  Qwest  has  built  a  two  billion  dollar  nationwide  fiber-optic 
network  as  a  backbone  to  its  telephone  service  [Ref.  5],  Alcatel  and  Fujitsu  Ltd.  are 
constructing  an  18,000  mile  undersea  WDM  optical  fiber  cable  looping  from  Australia 
and  New  Zealand  to  the  U.S.,  then  back  through  Hawaii  and  Fiji  to  Australia  [Ref.  6]. 

B.  HOME  NETWORKS  OF  THE  FUTURE  AND  THE  HOME 
COMMUNICATOR 

Thus  far  the  discussion  has  centered  on  the  technology  presently  available  that 
has  improved  the  operability  of  the  worldwide  internetworking  business  over  the  past  few 
decades.  Within  the  information  technology  field  it  has  not  been  standards  such  as 
IEEE  that  have  shaped  technology  evolutions  but  instead  consumer  practices  that  have 
dictated  which  standards  take  hold  of  the  business  world  environment  and  flourish.  As 
technology  increases  a  general  trend  has  seen  business-type  networking  environments 
being  introduced  into  the  home  environment  at  an  increasing  rate.  Individual 
homeowners  are  realizing  benefits  that  only  the  business  sector  has  seen  in  the  past. 
Networking  solutions  within  the  household  are  now  able  to  utilize  one  ISP  connection 
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and  span  it  out  to  several  computers  for  simultaneous  schoolwork,  business  work, 
and/or  entertainment  purposes. 

A  short  time  ago  in  order  for  the  homeowner  to  set  up  and  employ  a  networked 
environment  within  his  or  her  home  it  has  been  imperative  that  he  or  she  has  extensive 
experience  and  knowledge  of  networking.  Networking  is  not  intuitive  and  the  different 
interactions  between  Interior  Gateway  Protocols  (IGP)  and  Exterior  Gateway  Protocols 
(EGP)  can  be  confusing  to  an  untrained  individual.  The  business  world  has  begun 
meeting  this  challenge  by  creating  hardware  and  software  networked  systems  that  are 
easier  to  operate  regardless  of  the  level  of  experience  that  the  consumer  possesses. 

Optical  fiber  has  been  a  backbone  medium  utilized  by  telephone  companies  for 
over  a  decade  now  because  of  its  exceptional  bandwidth  capabilities.  Today  optical 
fiber  is  no  more  expensive  than  twisted  pair  cable.  Yet,  several  inhibiting  factors  have 
prevented  the  use  of  optical  fiber  within  the  average  household.  Today  a  majority  of  the 
industrialized  nations  have  comprehensive  telephone  networks.  90  to  100%  of  the 
households  within  these  industrialized  nations  already  possess  telephones  with  an 
existing  twisted  pair  infrastructure  up  to  and  within  the  household.  The  cost  to  rewire 
households  with  optical  fiber  has  thus  far  outweighed  any  added  bandwidth  benefits  to 
the  consumer.  Instead  it  has  been  more  convenient  to  utilize  the  existing  telephone  wire 
and  establish  a  new  cable  infrastructure  to  include  television  cable  service  to  the 
household.  In  addition,  existing  telephone  and  television  service  within  the  industrialized 
nations  has  proven  fairly  inexpensive  for  the  average  consumer. 

As  computer  and  internetworking  technology  continues  to  progress  bandwidth 
requirements  for  the  average  user  in  the  industrialized  countries  will  increase  as  well. 
Data  transfer  over  internet  has  already  been  integrated  with  voice  over  internet  and 
video  teleconferencing.  Each  of  these  services  within  the  home  will  add  increasing 
strains  on  the  existing  household  networking  medium  due  to  the  time  sensitive 
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necessities  along  with  increased  bandwidth  requirements.  As  the  computer  trend 
continues  to  grow  the  natural  next  progression  is  to  network  the  household 
communication  system  with  the  entertainment  system.  Instead  of  receiving  television 
and  telephone  service  separately  the  two  will  be  combined.  The  existing  household 
twisted  pair  will  not  be  able  to  maintain  such  a  networked  household  environment. 
Optical  fiber  rewire  of  households  will  be  considered  as  the  viable  solution  to 
accommodate  the  future  fully  networked  household. 

Another  scenario  that  must  be  noted  is  the  situation  within  developing  countries. 
The  existing  telephone  and  television  services  can  be  drastically  more  expensive  due  to 
monopolies  caused  by  political  corruption.  In  this  atmosphere  usually  there  is  little 
existing  infrastructure  to  the  majority  of  individual  households  for  telephone  or  television 
service  because  of  the  substantial  expense  to  the  middle  and  low  class  clientele.  With 
this  type  of  an  environment  together  with  the  history  of  growth  in  computer  technology  it 
would  be  more  prudent  to  design  a  complete  networked  infrastructure  utilizing  optical 
fiber  technology. 

Finally,  in  order  to  take  advantage  of  the  future  networked  household  there  must 
be  a  device  that  performs  as  the  networking  core.  Such  a  device  would  be  called  the 
home  communicator.  It  will  deliver  the  previously  discussed  innovative  networking 
improvements  down  to  the  customer  in  the  form  of  consolidated  functionality.  Presently 
customers  are  required  to  get  service  from  the  phone  company  in  order  to  receive 
telephone  service  and  cable  service  from  a  television  cable  company  in  order  to  receive 
an  increased  quality  of  television  reception.  In  addition,  utilization  of  a  cable  or 
telephone  ISP  would  give  the  customer  e-mail  and  internet  capability  with  either  the 
television  or  telephone,  but  no  service  presently  offers  all  three  in  one.  The  home 
communicator  would  allow  the  two  presently  unrelated  functions  of  television  and 
telephone  service  to  be  contained  within  one  package,  one  service  with  the  added 
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internetworking  capability.  Figure  1-1  demonstrates  the  functionality  of  the  home 
communicator. 


Figure  1-1  Home  Communicator  Functionality 

The  optical  fiber  household  network  in  conjunction  with  the  multipurpose 
multifunctional  communicator  would  allow  one  input  into  the  house  with  the  ability  to 
have  up  to  several  distinct  televisions  and  several  individual  telephone  lines  as  well  as 
providing  e-mail  and  web  browsing  capabilities  to  the  customer.  It  will  be  designed  as 
an  easy  to  set  up  and  use  instrument.  The  customer  is  not  required  to  have  networking 
experience  in  order  to  operate  the  home  communicator.  Its  functionality  will  be  the  most 
basic  for  the  original  lowest  costing  package.  Functionality  will  be  increased  with  greater 
priced  packages  depending  on  the  affluence  of  the  household.  More  televisions  and 
telephones  can  be  added  to  create  the  networked  environment  with  added  functionality 
to  the  basic  model.  Each  telephone  can  be  used  independently  or  in  unison.  Figure  1-2 
illustrates  the  household  with  a  future  network  utilizing  a  home  communicator  design. 
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C.  DOCUMENT  DESCRIPTION 


Chapter  II  of  this  thesis  describes  the  computer  operating  system  Linux  and  other 
software  packages  that  will  increase  capability  to  the  home  communicator.  Chapter  III 
discusses  Internet  Protocol  version  4  and  the  enhancements  of  the  protocol  in  the  area 
of  individual  packet  transfer  for  IP  version  6.  Chapter  III  also  investigates  the  IPv6 
addressing  scheme  for  a  possible  regionalization  proposal.  Chapter  IV  introduces  the 
high-level  requirements  and  high-level  design  for  the  home  communicator.  Chapter  V 
describes  a  six-month  plan  of  execution  to  produce  the  home  communicator  software 
and  hardware  package.  Chapter  VI  is  the  conclusion. 


E  M 


Home  Communicator 


Television 


H  Telephone 


Figure  1-2  Future  Household  with  Home  Communicator  and  Optical 
Fiber  Network 
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II.  LINUX  OPERATING  SYSTEM 


A.  INTRODUCTION  TO  LINUX 

Linus  Torvalds  developed  Linux  based  on  the  operating  system  UNIX.  Linux  is 
available  under  the  GNU  General  Public  License.  The  first  version  of  Linux,  0.02,  was 
available  on  the  internet  in  October  1991  [Ref  7:p.  6].  Linux  releases  are  controlled 
differently  than  any  other  popular  commercial  operating  system.  Inputs  from  computer 
programmers  all  over  the  world  are  received,  tested  and  added  to  the  kernel  for  next 
release  if  found  acceptable.  Linus  Torvalds  controls  which  contributions  become  part  of 
Linux  releases. 

The  new  trend  of  operating  system  programming  design  has  moved  towards 
microkernel  technology.  Microkernel  technology  utilizes  object-oriented  modules  to 
perform  the  system  functionality.  The  actual  kernel  module  provides  the  necessary 
minimum  functionality,  inter-process  communication  and  memory  management. 
Remaining  functions  of  the  operating  system  are  relocated  to  autonomous  processes. 
These  processes  communicate  with  the  kernel  through  clearly  defined  interfaces.  The 
drawback  to  this  philosophy  is  that  communication  between  these  secondary  functional 
modules  is  comparatively  time  intensive.  This  design  requires  faster  hardware  to 
prevent  noticeable  delays  in  processing.  Microsoft  is  following  the  microkernel  design 
for  its  present  and  future  Windows  packages.  [Ref  8:pp.  16-17] 

In  the  past,  design  architecture  for  operating  systems  has  focused  on  monolithic 
kernel  architecture.  Time  optimization  is  at  the  heart  of  the  monolithic  kernel.  The 
kernel  itself  has  all  the  functionality  of  the  operating  system  within  its  coded  module. 
Communication  between  the  different  function  elements  within  the  kernel  is  a  simple 
function  call.  Although  Linux'  kernel  is  modular  in  design  the  overall  philosophy  of  Linux 
design  utilizes  this  classic  monolithic  architectural  design.  Many  functions  of  the  kernel 
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that  could  be  removed  for  increased  modularity  remain  to  within  the  Linux  kernel 
because  it  reduces  the  process  time.  The  monolithic  design  affords  Linux  the  ability  to 
function  well  on  a  lower  end  computer  such  as  an  Intel  386  as  well  as  high  end  Pentium 
processors.  [Ref  8:pp.  16-17] 

1 .  Comparison  of  Linux  to  Microsoft  and  Apple  Computer 

Several  characteristics  of  presently  available  operating  systems  are  compared 
here  that  will  support  requirements  of  the  home  communicator  and  defend  a  conclusion 
of  Linux’  superiority  for  this  particular  purpose.  These  requirements  include  low  cost, 
software  storage  and  operation  size,  stability,  and  ability  to  configure  the  operating 
system  to  sustain  IPv6. 

Linux  is  less  expensive  than  Microsoft  or  Apple  Computer  products.  Microsoft 
requires  a  licensing  price  for  all  of  their  software  and  Apple  Computer  hardware  and 
software  packages  start  at  $1,599  [Ref  9],  Linux  utilizes  a  GNU  General  Public  License. 
The  only  costs  for  opting  with  Linux  would  be  developmental.  Also,  Linux  requires  much 
less  hard  drive  memory  and  RAM  to  run  than  Microsoft.  The  minimum  requirement  for 
the  WINDOWS  2000  server  solution  hardware  is  1  Gig  hard  drive  and  256  MB  RAM  [Ref 
10].  The  minimum  setup  of  the  Power  Mac  G4  is  10  Gig  hard  drive  and  64  MB  RAM 
[Ref  9].  Linux  can  easily  be  run  on  a  500  Meg  hard  drive  with  16  MB  RAM  due  to  its 
monolithic  background  design. 

It  is  no  secret  that  Microsoft  Operating  systems  have  a  poor  reputation  for  long¬ 
term  user  stability.  Linux  on  the  other  hand  has  a  strong  reputation  for  stability.  Apple 
Computer  has  also  enjoyed  a  very  solid  reputation  for  its  equipment  and  software. 
However,  a  detracting  factor  is  that  Apple  Computer  requires  the  purchase  of  their 
hardware  and  operating  system  software  together. 
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A  final  aspect  of  Linux  that  outweighs  its  counterparts  is  the  ability  for  anyone  to 
configure  IPv6  into  the  Linux  operating  system.  Microsoft  and  Apple  Computer  have  not 
offered  the  IPv6  functionality  up  to  this  point.  Microsoft  has  only  just  recently  offered  an 
IPv6  beta  version  stack  [Ref  1 1].  Linux  on  the  other  hand,  is  openly  configurable  due  to 
the  GNU  General  Public  License. 

2.  Linux  Distributions 

Linux  can  be  acquired  through  distributions.  There  are  several  major 
distributions  of  Linux  available  today.  Any  company  can  create  their  own  distribution  as 
long  as  the  source  code  for  the  Linux  kernel  portion  is  made  publicly  available.  Often  a 
company  will  create  a  Graphical  User  Interface  (GUI)  for  installation  ease  and/or  other 
small  software  programs  to  run  with  Linux  as  part  of  their  distribution  package.  In  this 
case  it  will  cost  more  than  a  nominal  DC-ROM  creation  fee  to  the  customer.  This  GUI 
for  installation  and/or  the  additional  software  is  usually  not  included  in  the  GNU  General 
Public  License  and  is  considered  proprietary.  In  this  case  a  license  would  have  to  be 
purchased  for  computers  the  software  is  loaded  on. 

For  the  purposes  of  this  study  there  is  no  requirement  for  ease  of  customer 
installation.  The  goal  here  is  to  create  a  software  system  and  image  the  file  to  install  on 
all  other  manufactured  systems.  The  customer  would  not  do  the  installation,  the 
hardware  system  would  come  to  him  or  her  preloaded  with  software  and  ready  to  plug  in 
and  turn  on. 

Overall  there  are  approximately  25  fully  capable  English  distributions  of  Linux 
available  today.  A  few  of  the  major  distributions  are  enhanced  and  released  by  other 
companies.  For  instance,  Corel,  Libranet  and  StormLinux  2000  all  utilize  the  Debian 
release  for  their  basic  Linux  kernel.  Some  of  the  most  popular  versions  include  Debian, 
Red  Hat,  and  Slackware.  Each  of  these  adds  their  own  additional  software  programs 


13 


and/or  their  own  GUI  installation  packages  as  a  supplement  to  the  Linux  operating 
system.  The  majority  of  the  Linux  distributions  cater  to  IBM  clone  processors  although 
the  MkLinux  and  PowerPC  2000  are  strictly  designed  to  work  on  the  power  Macintosh 
platforms.  Presently  on  the  same  web  page  there  are  14  mini  and  specialty 
distributions.  Several  of  them  are  specifically  created  to  operate  as  a  secondary 
operating  system  to  the  Windows  environment.  [Ref  12] 

3.  Investigation  of  Existing  Linux  Distributions 

It  is  possible  to  download  a  complete  version  of  the  Linux  operating  system  from 
any  of  the  various  Linux  distribution  web  pages.  The  documentation  to  load  and 
configure  the  software  is  also  available  through  web  pages  such  as: 
http://MetaLab.unc.edu/LDP/HOWTO.  The  earlier  versions  of  the  Linux  kernel  are  not 
supported  as  well  as  the  latest  2.0  versions.  Therefore  it  would  be  prudent  to  utilize  the 
latest  2.1  Version  to  develop  the  software  package.  A  hardware  system  could  be 
designed  easily  and  cheaply  in  today’s  environment  to  accommodate  the  RAM  and 
memory  storage  requirements  of  the  newer  and  larger  Linux  kernel. 

In  order  to  test  feasibility  of  obtaining  Linux  without  cost  the  author  downloaded 
Linux  from  web  sites  listed  in  Table  2-1.  Debian  CDs  were  constructed  from  a  Debian 
CD-ROM  setup  guide  then  loaded  onto  an  Intel  Pentium  100MHz  computer.  The 
installation  of  a  basic  kernel  was  accomplished  by  following  the  menu  driven  selection 
process.  Each  distribution  investigated  had  its  own  GUI  installation  software  but  all 
installation  GUI’s  accomplished  the  same  functions.  The  next  section  discusses  the 
various  GUI  interfaces  available  for  the  Linux  kernel. 
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Company  Name  Home  Web  Site 

Debian:  http://www.debian.org/ 

Corel:  http://linux.corel.com/ 

PowerPC  2000:  http://www.linuxppc.com/ 

White  Dwarf:  http://www.emjembedded.com/ 

Table  2-1  List  of  Linux  software  Home  Web  Sites 

4.  Linux  Desktop  Environment  Examination 

Linux  has  been  well  known  for  its  utilization  of  a  command  line  interface.  There 
has  not  been  a  substantial  Linux  GUI  desktop  solution  available  to  the  customer  until 
recently.  Where  Microsoft  and  Apple  Computer  have  developed  operating  systems  with 
the  window  manager  and  desktop  environment  built  in,  Linux  has  remained  a  command¬ 
line  based  environment.  Other  software  packages  have  been  developed  that  offer  a 
graphical  user  interface  functionality  but  these  software  packages  actually  operate 
separately  from  the  UNIX  and  Linux  kernels. 

Several  of  the  more  popular  GUI  software  packages  for  the  Linux  kernel  are 
listed  in  Table  2-2.  The  software  GUI  systems  listed  to  the  left  side  of  Table  2-1  must  be 
installed  and  functional  prior  to  the  software  systems  listed  to  the  right  of  the  chart.  In 
other  words  any  one  of  the  Window  Manager  software  operates  as  an  add-on  to  the  X- 
Window  System;  the  Desktop  Environment  software  requires  both  an  operational  X- 
Window  System  and  a  Window  Manager  to  be  installed  beforehand.  Each  of  these 
software  packages  described  is  included  under  the  GNU  General  Public  License  and 
can  be  downloaded  from  parent  company  sites  for  installation  on  Linux  systems. 

The  X  Window  System  was  the  first  attempt  at  a  GUI  for  UNIX  systems.  It  took 
shape  in  the  late  1980's  prior  to  Linux'  inception.  X  Window  System  is  not  technically  a 
desktop  environment  or  a  window  manager.  Instead,  X  Window  System  was  developed 
for  the  UNIX  environment  with  the  goal  of  allowing  applications  to  be  running  from  the 
one  computer  yet  be  displayed  on  more  than  one  computer  at  the  same  time  [Ref  7:p. 
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162].  Although  it  provides  a  windowing  environment  for  Linux  it  alone  is  lacking  certain 
functionality  that  is  required  in  day-to-day  performance  of  a  desktop  environment  or 
window  manager. 


X-Window  System 

Window  Manager 

Desktop  Environment 

Provides: 

basic  window 
evolutions  only 

opening,  resizing, 
and  closing  "function" 
or  "program"  windows 

overall  user  control  including 
drag  &  drop,  paneling, 
file  management,  etc. 

Specific 

Name(s): 

XFREE86 

twm 

fvwm 

Enlightenment 

★ 

GNOME 

KDE 

*  to  maintain  brevity  other  window  managers  readily  available  are  not  specifically  discussed  here 
Table  2-2  Linux  GUI  and  windowing  software 


X  Window  System  possesses  several  deficiencies  for  a  normal  computer  user.  X 
Window  System  does  not  support  the  ability  to  drag  icons  onto  the  desktop,  does  not 
have  either  an  integrated  file  manager,  a  unified  help  system  for  applications,  or  utilities 
such  as  clocks,  calendars,  and  calculators.  It  was  not  developed  to  offer  desktop 
functionality  and  therefore  lacks  the  actual  capabilities  that  would  be  required  by  a 
standard  computer  workstation  consumer.  XFree86  is  the  edition  of  the  X  Window 
System  that  supports  the  Linux  platform.  Note  that  the  protocol  X  Window  System 
utilizes  between  the  server  and  client  computers  is  TCP/IP  even  when  directly 
connected  [Ref  7:p.  15]. 

In  order  for  X  Window  System  to  ever  approach  the  functionality  and  feel  of 
Windows  or  Macintosh  it  is  necessary  to  utilize  a  window  manager  in  addition  to  the  X 
Window  System.  The  window  manager  would  embody  the  layer  of  software  between 
the  customer  and  the  X  Window  System  software.  The  X  Window  System  software 
would  correspond  to  the  interface  between  the  window  manager  and  the  Linux  kernel. 
The  X  Window  System  software  is  required  to  run  the  window  managers  available  for 
Linux. 
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Overall,  the  window  manager  for  Linux  provides  features  for  opening,  resizing, 
and  closing  function  or  program  windows.  All  of  the  window  manager  packages  allow 
the  user  the  functionality  to  configure  the  appearance  of  the  window  frames  to  his  or  her 
specific  requirements.  Window  managers  offer  such  provisions  as  titlebars,  shaped 
windows,  user  defined  macro  functions,  icon  management,  and  user  configured  key  and 
pointer  button  bindings.  There  are  many  window  managers  available  today  and  most 
come  under  the  GNU  General  Public  License.  Some  of  the  most  popular  include  twm 
(Tab  Window  Manager),  fvwm  (Virtual  Window  Manager),  and  Enlightenment,  which  are 
described  here. 

twm  is  the  only  window  manager  that  is  distributed  with  the  X-System  or  XFree86 
package,  twm  offers  the  window  manager  functionality  discussed  above.  When  started 
without  any  other  type  of  session  manager  twm  will  execute  to  the  foreground  as  the  last 
client.  When  twm  is  terminated  the  session  is  automatically  terminated,  twm  is  more 
difficult  to  handle  than  other  window  managers  that  have  been  developed  for  Linux.  [Ref 
13:p.  263] 

fvwm  was  derived  from  twm.  fvwm  is  a  popular  window  environment  with  Linux 
because  it  combines  ease  of  use  with  low  memory  consumption,  fvwm  utilizes 
approximately  one  half  to  one  third  the  memory  consumption  of  the  twm  window 
manager,  fvwm  is  available  in  three  versions,  1.2n,  2.0,  and  fvwm95.  Version  1.2n  has 
the  lowest  memory  consumption.  Version  2.0  offers  more  configurations  possibilities. 
fvwm95  has  a  similar  environment  impression  to  existing  Windows  and  Macintosh 
operating  systems.  [Ref  13:p.  272]  Several  other  window  managers  not  described  here 
are  derivatives  of  fvwm  such  as  AfterStep  and  LessTif  [Ref  14:pp.  68-69]. 

The  Enlightenment  Window  Manager  supports  all  the  functionality  described 
above.  The  software  package  is  not  a  derivative  of  twm  or  fvwm.  Compared  to  other 
window  managers  Enlightenment  offers  added  user  configuration  of  the  function  and 
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program  windows  by  offering  customization  themes  to  the  user.  These  themes  allow  the 
user  to  create  individual  window  environments  unequaled  by  other  window  managers. 
Enlightenment  is  presently  the  only  window  manager  100%  compatible  with  the  desktop 
environment  GNOME  described  below.  [Ref  14:pp.  69-70] 

Desktop  Environments  are  the  next  step  in  the  GUI  creation  for  the  UNIX  and 
Linux  operating  systems.  Where  window  managers  control  the  function  and  program 
windows  for  the  X  Window  System  the  desktop  environment  offers  overall  user  control 
down  to  the  underlying  Linux  operating  kernel.  The  desktop  environment  utilizes  a 
specific  or  several  window  managers  to  support  the  window  functionality  within  the 
desktop  view.  The  desktop  environments  offer  the  following  features  to  X-Windows 
functionality:  Drag  and  Drop,  Drive  Icons,  Paneling,  Integrated  File  Management, 
Integrated  Session  Management,  and  Inter-process  Communication  between 
Applications  [Ref  14:pp.  74-77], 

The  desktop  environment  adds  capabilities  to  the  window  manager’s 
functionality.  One  added  capability  by  the  desktop  environments  not  found  with  window 
managers  alone  is  the  ability  to  start  often  used  programs  from  a  menu.  Another 
desktop  environment  benefit  is  the  distinct  applications  developed  for  desktop  usage 
such  as  calculator,  simple  text  editor,  and  file  manager.  Once  the  Linux,  X  Window 
System,  Window  Manager,  and  Desktop  Environment  are  set  up  it  appears  as  one  intact 
package  to  the  customer.  The  most  common  X-Windows  window  environments 
available  are  GNOME  (GNU  Object  Model  Environment)  and  KDE  (K  Desktop 
Environment).  The  following  are  short  descriptions  of  these  Linux  desktop 
environments. 

GNOME  stands  for  GNU  Object  Model  Environment.  It  was  developed  from  the 
beginning  on  open-source  principles.  GNOME  utilizes  the  GNU  toolkit  called  GTK+  for 
development.  GNOME  does  not  have  its  own  window  manager  but  can  be  utilized  with 


18 


any  window  manager  that  is  GNOME  compliant.  Presently  only  the  window  manager 
Enlightenment  is  100%  GNOME  compliant.  [Ref  14:pp.  74-77] 

GNOME'S  look  and  feel  is  similar  to  the  Windows  or  Macintosh  desktop 
environment.  It  allows  items  to  be  placed  on  the  desktop  that  can  be  manipulated  using 
right  click  menus  or  execution  by  a  left  click  of  the  mouse.  GNOME  is  not  quite  as 
finished  a  product  as  either  of  the  other  two  major  operating  system  companies,  but  the 
same  functionality  found  in  Windows  or  Macintosh  environments  is  present  within  the 
GNOME  GUI. 

GNOME  has  a  menu  panel  across  the  bottom  of  the  screen  that  can  be 
programmed  to  hold  buttons  for  most  often  used  operations.  This  menu  panel  is  in 
addition  to  the  programmable  desktop  icons  found  on  the  desktop  portion  of  the  screen. 
The  menu  panel  would  be  particularly  useful  for  the  customer  utilizing  the  home 
communicator.  The  customer  could  have  full  view  of  other  available  applications  while 
another  deployed  application  might  have  covered  the  desktop  icons.  A  standard  menu 
panel  could  be  developed  to  deploy  all  the  functions  from  individual  buttons  across  the 
bottom  menu  panel.  [Ref  15]  GNOME  desktop  default  offers  4  separate  desktops 
simultaneously  and  can  be  configurable  up  to  64  desktops.  The  bottom  panel 
possesses  the  desktop  selection  screen  for  the  customer’s  convenience. 

The  GNOME  desktop  is  highly  configurable.  The  customer  can  either  utilize  the 
design  provided  or  they  can  reconfigure  the  buttons  and  icons  to  support  personal 
requirements  depending  on  their  level  of  computer  knowledge.  GNOME  also  contains  a 
set  of  standard  desktop  tools  and  applications  including  a  simple  text  editor  (gEdit)  and 
chat  (xchat  IRC  client).  These  specifically  support  requirements  for  the  home 
communicator  concept.  [Ref  15] 

KDE  is  short  for  K  Desktop  Environment.  KDE  is  usually  operated  with  the 
window  manager  kwm.  KDE  utilizes  the  Qt  toolkit  for  development.  Initially,  Qt  toolkit 
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did  not  fall  under  the  GNU  General  Public  License,  but  the  license  has  since  been 
modified  to  fall  under  GNU.  KDE  desktop  comes  under  the  GNU  General  Public 
License.  KDE  is  more  mature  than  GNOME  specifically  with  the  KDE  applications.  KDE 
was  begun  as  a  project  in  1996  by  German  LyX  developer  Matthias  Ettrich.  The 
developer  base  quickly  grew  into  a  group  of  interested  programmers  similar  to  the 
growth  of  Linux  itself.  The  first  stable  release,  1.0,  was  released  in  July  of  1998  and 
KDE  is  presently  on  release  1.1.  [Ref  7:p.  612] 

Similar  to  GNOME,  KDE  has  a  look  and  feel  that  approaches  Windows  and 
Macintosh  operating  systems.  KDE  also  allows  items  to  be  placed  on  the  desktop  that 
can  be  manipulated  using  right  click  menus  or  execution  by  a  left  click  of  the  mouse. 

KDE  displays  buttons  on  the  lower  panel  that  correspond  to  available  applications.  Like 
with  GNOME  the  KDE  panel  can  be  configured  to  display  the  applications  available  to 
the  customer  on  this  bottom  panel.  If  the  desktop  is  covered  with  a  deployed  application 
the  bottom  panel  allows  the  customer  continuous  view  of  his  or  her  options. 

There  are  some  additional  qualities  found  in  KDE  that  are  not  found  with 
GNOME.  KDE  has  the  same  bottom  panel  that  allows  activation  of  common  programs 
and  the  capability  of  configuring  up  to  64  simultaneous  desktops.  Yet,  KDE  has  a 
second  panel  across  the  top  of  the  screen  that  holds  an  individual  button  for  all  activated 
applications.  When  a  button  on  the  top  panel  is  pressed  by  a  mouse  click  the  screen 
automatically  moves  to  the  desktop  the  button's  program  is  located  on.  GNOME 
requires  the  customer  to  remember  which  screen  the  program  is  located  on  and 
specifically  request  the  screen  to  get  to  the  application. 

Similar  to  GNOME,  KDE  is  highly  configurable.  The  customer  can  either  utilized 
the  design  provided  or  they  can  reconfigure  the  buttons  and  icons  to  support  personal 
requirements  depending  on  their  level  of  computer  knowledge.  KDE  also  contains  a  set 
of  standard  desktop  tools  and  applications  including  a  simple  text  editor  (Text  Edit)  and 


chat  (Chat  Client  -  ksirc).  These  specifically  support  requirements  for  the  home 
communicator  concept.  [Ref  16] 

B.  APPLICATION  SOFTWARE  FOR  LINUX 

Although  Linux  is  not  as  popular  as  Microsoft  or  Apple  Computer  there  are  a 
growing  number  of  companies  that  are  developing  applications  compatible  with  the  Linux 
operating  system.  There  is  a  requirement  to  locate  functionality  for  web  browsing,  IP 
telephony,  e-mail,  chat,  and  text  editing.  In  order  to  develop  the  home  communicator 
software  package  it  is  necessary  to  canvas  existing  application  software  available  to  the 
Linux  system. 

1 .  Web  Browser 

Netscape  and  Internet  Explorer  are  the  most  popular  browsers  available  today. 
Internet  Explorer,  does  not  offer  a  version  that  supports  Linux.  Internet  Explorer  is 
available  for  HP-UX  and  Solaris  only  and  cannot  be  used  with  Linux  without  major 
modification  [Ref  17].  Therefore,  Netscape  is  investigated  here  as  a  possible  application 
to  support  the  home  communicator. 

Netscape  presently  only  has  an  English  version  available  for  the  Linux  operating 
system  [Ref  18].  This  would  affect  the  usage  of  the  home  communicator  in  foreign 
countries.  The  software  will  function,  but  the  view  of  the  Netscape  browser  itself  will  be 
in  English.  For  the  countries  that  use  oriental  languages  there  is  a  greater  concern  with 
Netscape.  The  oriental  alphabet  requires  two  bytes  of  code  for  each  character  where 
English  and  European  languages  only  require  one  byte  of  code  for  each  character  [Ref 
18].  The  English  version  of  Netscape  cannot  be  utilized  with  the  oriental  version  of  Linux 
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for  this  reason.  They  are  incompatible.  Until  Netscape  develops  an  oriental  language 
version  Netscape  could  not  be  utilized  for  oriental  versions  of  the  home  communicator. 

Netscape  has  other  functionality  to  offer  to  the  home  communicator.  There  is  a 
chat  and  e-mail  function  within  the  full  Netscape  Communicator  package.  Netscape 
functionality  for  these  requirements  will  be  discussed  below  within  each  individual 
section. 

2.  IP  Telephony 

There  are  several  peripheral  items  to  consider  when  attempting  development  of  a 
Voice  over  IP  (VoIP)  system.  The  first  major  decision  for  VoIP  is  the  designed  footprint 
of  the  customer  base.  If  the  VoIP  application  is  functional  only  home  communicator  to 
home  communicator  such  as  the  chat  service  is  computer  to  computer  then  a  problem 
arises  that  persons  purchasing  the  home  communicator  can  only  converse  with  others 
that  already  own  the  home  communicator;  this  is  definitely  unsatisfactory  from  a 
customer  standpoint.  In  order  to  effectively  retail  this  technology  to  the  consumer  it 
would  be  important  to  literally  flood  a  customer  base  with  the  product.  Within 
industrialized  nations  this  would  be  a  difficult  task.  The  existing  public  telephone  service 
is  so  prevalent  that  it  would  be  difficult  to  sell  the  home  communicator.  Yet,  in  a  country 
that  is  deprived  of  low  costing  telephone  service  due  to  existing  monopolies  the  home 
communicator  could  possibly  be  flooded  into  the  market  if  its  cost  was  reasonable. 

Speak  Freely  offers  this  type  of  VoIP  technology.  Speak  Freely  is  offered  as 
Open  Source  Software,  with  no  purchase  required.  It  allows  computer  users  to  connect 
to  other  computers  presently  on  the  internet.  This  technology  does  not  work  in 
conjunction  with  the  public  telephone  system,  though.  It  presently  supports  only  on  line 
computer  to  computer  connection.  The  Speak  Freely  customers  utilize  a  Look  Who's 
Listening  server  to  publish  their  information  into  searching  directories.  Another  point 
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worth  making  here  is  that  presently  the  UNIX  version  of  Speak  Freely  is  not  GUI 
supported.  The  present  UNIX  version  is  7.0  and  it  is  a  command  line  application.  There 
is  a  working  group  presently  developing  an  X  Windows  upgrade  to  the  UNIX  package  of 
Speak  Freely.  Other  companies  such  as  PhoneFree  supply  similar  software  for  no  cost 
to  customers.  However,  they  do  not  support  the  Linux  operating  systems.  [Ref  1 9] 

On  the  other  hand,  if  the  system  is  going  to  be  interactive  with  the  normal  public 
phone  service  there  must  be  an  interface  point  to  the  public  phone  system.  This 
requires  a  company  offering  the  VoIP  service  to  develop  and  deploy  a  gateway 
infrastructure  supporting  the  link  to  the  public  telephone  system  or  to  utilize  just  such  a 
low  cost  service  from  a  preexisting  service  company  in  order  to  offer  VoIP  to  the 
customer  at  a  low  cost.  The  cost  of  utilizing  such  a  service  from  another  company  would 
impact  home  communicator  service  costs.  This  would  offer  a  larger  VoIP  footprint  to  the 
customer  than  Speak  Freely  offers. 

Dialpad.com  displays  this  type  of  VoIP  technology  that  is  available  today. 
Dialpad.com  is  a  web  site  that  offers  free  telephone  calls  anywhere  in  the  United  States 
through  the  computer.  Anyone  would  utilize  the  web  browser,  such  as  Netscape  to 
access  the  dialpad.com  web  site.  Once  on  the  dialpad.com  site  it  is  a  simple  matter  of 
requesting  a  free  account  by  following  a  simple  registration  process.  The  only 
requirement  for  the  user  is  that  the  computer  they  utilize  has  a  speaker  and  microphone. 
One  drawback  to  this  technology  is  that  persons  can  only  call  regular  public  service 
telephones.  [Ref  20]  For  instance,  there  is  no  capability  with  dialpad.com  to  call  another 
computer  set  up  with  dialpad.com  access.  Presently  dialpad.com  is  only  available  for 
use  within  the  United  States. 

Another  technology  presently  available  for  this  type  service  is  IP  telephones. 
Cisco  has  released  IP  telephones  that  presently  cost  approximately  $400.  These 
telephones  look  and  perform  as  a  normal  telephone,  but  they  plug  directly  into  an 
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existing  LAN  with  an  IP  address.  They  possess  a  regular  telephone  number.  These 
telephones  require  an  entire  infrastructure  to  be  connected  to  the  public  telephone 
system.  This  overall  required  computer  server  infrastructure  is  quite  costly.  With  IP 
telephones  within  the  home  communicator  the  functionality  to  call  home  communicator 
to  home  communicator,  home  communicator  to  pubic  telephone  customer,  and  public 
telephone  customer  to  home  communicator  is  realized,  though.  [Ref  21] 

There  is  an  option  that  would  require  investigation.  This  option  would  support  the 
functionality  found  with  IP  telephony  utilizing  standard  telephones.  The  home 
communicator  would  be  configured  as  a  server  and  each  telephone  connection  within 
the  home  communicator  would  utilize  individual  NIC  cards.  Each  NIC  card  would 
possess  an  individual  IP  address.  The  server  itself  (home  communicator)  would  process 
the  incoming  telephone  signals  and  pass  onto  the  telephone  only  the  raw  sound  IP 
packets.  Each  NIC  IP  address  would  correspond  to  individual  telephone  numbers. 

There  would  be  a  different  number  for  each  telephone  and  another  number  for  all  the 
phones  if  the  caller  wanted  to  locate  anyone  within  the  house  instead  of  a  specific 
person  within  the  household.  This  type  system  along  with  IP  telephones  offers  the 
largest  footprint  to  the  home  communicator  customer.  This  technology  is  not  presently 
available,  though,  and  would  require  extensive  design  and  development. 

3.  E-mail  Capability 

E-mail  capability  requires  support  to  the  customer  by  the  ISP.  The  DNS  server 
name  (for  example,  "@home.com")  for  each  customer  must  be  obtained  from  the  ISP  as 
a  portion  of  the  monthly  service  fee.  In  this  case  the  home  communicator  would  be  sold 
as  the  hardware  to  be  used  with  the  home  communicator  ISP  service  to  support  the  24 
hour  7  day  per  week  internet  connection.  If  the  home  communicator  is  set  up  like  a  mail 
client  the  customers  would  require  mail  storage  on  mail  servers  at  the  ISP  location  even 
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though  the  home  communicator  is  designed  to  be  active  24/7.  If  the  home 
communicator  were  configured  as  both  a  mail  server  with  the  mail  client  the  customer 
would  not  be  required  to  maintain  the  client  open  24/7.  The  mail  server  would  store  the 
incoming  e-mail  whether  or  not  the  mail  client  was  activated.  If  the  home  communicator 
is  configured  with  the  mail  server  concept  the  ISP  would  require  only  mail  transfer 
agents  instead  of  mail  server  assistance. 

The  actual  mail  client  software  can  be  found  within  several  of  the  software 
packages  discussed  above.  E-mail  client  capability  is  offered  with  Netscape 
Communicator.  Netscape  supports  POP3  and  IMAP  protocol  mail  accounts.  Netscape 
presently  supports  an  offer  of  a  free  mail  account  through  USA.NET  to  anyone  who 
registers.  The  free  mail  account  only  permits  up  to  5  MB  free  mail  storage  and 
considers  an  account  inactive  after  90  days  of  no  activity.  There  is  no  guarantee  as  to 
how  long  other  free  services  such  as  the  USA.NET  will  be  offered  and  thus  cannot  be 
trusted  as  a  viable  option  for  clients.  [Ref  18]  KDE  desktop  also  has  an  e-mail  capability 
application  called  kmail.  kmail  will  support  the  same  functionality  of  Netscape  mail  client 
service  except  it  does  not  support  IMAP  accounts. 

In  order  to  maintain  consistency  of  the  home  communicator  software  package 
the  KDE  desktop  e-mail  client  application  (kmail)  should  be  utilized  for  the  home 
communicator  regardless  of  how  the  mail  server  concept  is  managed.  It  would  be 
necessary  to  test  feasibility  of  mail  server,  Linux  server,  and  mail  client  workstation  all 
within  the  same  Linux  operating  system  prior  to  actual  deployment  of  the  concept. 
Limitations  should  be  set  on  storage  size  with  automatic  timed  deletion  of  e-mails  on  the 
mail  server. 
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4. 


Chat 


Chat  allows  persons  utilizing  the  internet  to  contact  others  that  are  presently  on 
line  and  registered  with  a  chat  server.  Once  a  connection  between  customers  is  made 
Chat  allows  the  users  to  converse  by  typing  information  and  pressing  the  Enter  key  to 
send.  Chat  functionality  can  be  added  to  the  home  communicator  through  any  of 
several  avenues.  Netscape  supports  chat  functionality  directly  from  the  top  menu  as 
Instant  Messenger.  Anyone  can  sign  up  for  free  user  status.  Netscape  chat  functionality 
does  not  require  the  web  browser  to  be  opened  in  order  to  run  Instant  Messenger. 
GNOME  and  KDE  desktop  environments  also  support  chat  functionality  through  their 
own  applications,  xchat  IRC  client  or  Chat  Client  respectively.  In  order  to  simplify  the 
home  communicator  for  the  non-sawy  computer  users  a  menu  panel  button  would  be 
programmed  to  deploy  the  chat  function  regardless  of  which  version,  KDE  or  Netscape 
is  utilized. 

5.  Simple  Text  Editor 

Simple  text  editor  capability  can  be  added  directly  through  the  desktop 
environments  of  Linux.  There  is  a  simple  text  editor  function  included  within  both  KDE 
(Text  Editor)  and  GNOME  (gEdit)  software  packages.  During  development  of  the  home 
communicator  package  the  application  for  simple  text  editor  would  be  included.  In  order 
to  simplify  the  home  communicator  for  the  non-sawy  computer  users  a  menu  panel 
button  would  be  programmed  to  deploy  the  simple  text  editor. 

Another  possible  choice  for  simple  text  editor  capability  that  should  be  noted  here 
is  Star  Office.  Star  Office  is  another  GNU  General  Public  License  software  compatible 
with  the  Linux  operating  system.  Star  Office  is  a  Sun  Microsystems  product  that  offers 
the  common  desktop  functions  of  word  processor,  spreadsheet,  and  slide  presentation 
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developer.  This  product  would  far  surpass  the  simple  text  editor  requirement  but  would 
greatly  increase  a  user’s  capability  with  no  added  cost.  It  must  be  noted,  though,  that  it 
would  also  increase  the  complexity  of  product  operation  as  well  as  force  an  increase  in 
the  hardware  requirement  for  hard  drive  space  and  Ready  Access  Memory  (RAM). 
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III.  INTERNET  PROTOCOL,  VERSION  4  VERSUS  VERSION  6 


A.  IPv4  BACKGROUND 

The  first  packet  switch  network  was  a  four-node  packet  switching  network  known 
as  Advanced  Research  Projects  Agency  Network  (ARPANET).  It  went  into  operation  in 
1969.  The  protocols  utilized  for  the  original  ARPANET  were  subject  to  network  crashes 
and  operated  rather  slowly.  In  1974  a  new  suite  of  internet  protocols  known  as  TCP/IP 
was  proposed  by  Vinton  G.  Cerf  and  Robert  E.  Kahn.  By  1983  all  existing  ARPANET 
nodes  (approximately  300)  were  converted  to  these  new  TCP/IP  protocols.  In  1 983  the 
Department  of  Defense  adopted  TCP/IP  as  its  protocol  standard,  which  had  spawned  a 
large  market  for  the  technology.  Throughout  the  1 980s  the  government  funded  various 
UNIX  developers  to  build  the  TCP/IP  suite  for  UNIX  systems.  Regional  Service  Provider 
organizations  developed  around  the  world  to  support  connections  to  the  internet.  The 
ARPANET  remained  the  backbone  of  a  growing  evolution  of  academic  and  commercial 
research  networks.  By  1994,  when  the  Internet  was  officially  changed  from  a  research 
testbed  to  a  commercial  service  network  it  was  made  up  of  millions  of  interconnected 
computers.  Today  IPv4  is  utilized  throughout  the  internet.  [Ref  22:pp.  10-11] 

The  IP  protocol  utilizes  encapsulation  to  deliver  data.  A  simplistic  definition  of  IP 
protocol  follows.  IP  operates  by  accepting  data  from  the  next  higher  protocol,  either 
TCP  or  UDP,  creating  a  datagram,  routing  it  through  the  network,  and  delivering  it  to  the 
recipient  host  and  then  pertinent  application.  IP  uses  the  subnet  mask  and  IP  routing 
tables  to  deliver  the  datagram  to  the  next  router  or  host  on  the  path  to  the  destination. 
The  subnet  mask  helps  determine  whether  or  not  the  source  node  is  on  the  same  LAN 
as  the  destination.  The  routing  table  designates  how  the  IP  packet  is  routed  when  the 
destination  node  is  not  on  the  same  LAN  as  the  source  node.  All  routers  and  hosts 
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connected  to  a  network  and  the  internet  have  a  routing  table  which  defines  the  nodes 
within  range  of  it.  By  routing  to  the  next  hop  designated  within  each  router  or  host 
routing  table  the  datagram  is  transferred  from  source  to  destination. 

Figure  3-1  illustrates  the  fields  required  for  an  IPv4  datagram  packet.  The  most 
important  fields  within  the  IPv4  header  are  version,  source  IP  address,  destination  IP 
address,  and  protocol.  The  version  field  establishes  the  version  of  IP  being  utilized.  The 
source  IP  address  and  destination  IP  address  designate  where  the  datagram  is  coming 
from  and  where  it  is  going  to  by  IP  address.  The  protocol  field  transfers  the  data  packets 
to  the  appropriate  application  service  within  the  destination  host  such  as  TCP  or  UDP. 
Other  fields  such  as  the  Precedence/Type  of  Service  and  the  Option  fields  offer 
additional  options  to  IP.  Three  bits  hold  precedence  levels  are  0  through  7,  7  being  the 
highest  priority.  Four  bits  hold  type  of  service  to  depict  options  such  as:  minimize 
monetary  cost,  maximize  reliability,  maximize  throughput,  minimize  delay,  or  maximize 
security. 

Other  options  available  with  the  Options  field  include  possible  routing  controls, 
basic  security,  extended  security,  and  router  alert.  Routing  controls  include  strict  source 
route,  loose  source  route,  and  record  route.  Strict  source  route  as  it  sounds  describes  a 
complete  path  that  must  be  followed  to  the  destination  while  loose  source  route 
designates  milestones  along  the  way.  Record  route  contains  the  list  of  IP  addresses  of 
routers  that  were  visited  by  the  datagram.  Basic  security  assures  that  the  sending  host 
is  authorized  to  transmit  it,  intermediate  routers  appropriately  relay  it,  and  that  receiving 
hosts  are  allowed  to  receive  it.  The  option  parameters  for  basic  security  range  from 
Unclassified  to  Top  Secret.  There  are  flags  that  identify  the  protection  authority,  such  as 
Central  Intelligence  Agency  or  Department  of  Energy,  whose  rules  apply  to  the 
datagram.  The  extended  security  field  can  be  found  with  the  basic  security  option  field. 
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There  are  several  different  formats  for  this  option,  depending  on  the  needs  of  the 
defining  authority.  The  router  alert  is  to  let  routers  along  the  way  know  that  they  should 
examine  the  datagram  carefully  because  of  special  processing  requirements. 

0  1  2  3 

12345678901234567890123456789012 

|  Ver  |  HL  | Type  of  Service]  Datagram  Length  | 
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Figure  3-1  IPv4  Datagram  Packet  Header  Format 

Other  fields  within  the  IPv4  header  that  support  fragmentation  of  IPv4  packets 

include  header  length,  length  of  datagram,  identification,  flags,  and  fragment  offset.  The 
header  length  is  necessary  since  use  of  the  option  fields  will  create  a  longer  header 
when  utilized.  The  IPv4  header  can  be  20  bytes  to  60  bytes.  The  length  of  datagram  is 
important  for  network  traffic.  If  during  the  routing  of  the  datagram  packet  a  network 
maximum  frame  size  prevents  the  pass  through  of  the  existing  packet  it  must  be 
fragmented.  The  identification  field  consists  of  a  16-bit  number  that  designates 
fragmented  datagram  packets  as  initially  coming  from  the  same  packet. 

Flags  and  fragment  offset  fields  work  together  to  describe  the  specific  location  of 
the  fragment  within  the  original  packet.  One  bit  within  the  flag  field  indicates  whether  or 
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not  the  packet  may  be  fragmented.  The  fragment  offset  is  a  13-bit  field  that  displays 
what  is  known  as  the  fragment  block.  The  original  datagram  packet  is  broken  into  8-bit 
blocks  known  as  fragment  blocks.  The  13-bit  field  displays  this  fragment  block  value 
from  0  to  8191,  which  directly  corresponds  to  a  0  to  65,528-bit  offset  from  the  original 
datagram  packet.  Another  bit  within  the  flag  field  shows  if  this  is  the  last  fragment  of  the 
original  datagram  or  more  come  after  this  particular  block. 

Finally,  the  time  to  live  and  header  checksum  fields  within  the  IPv4  header  are 
utilized  for  network  cleaning  functions.  The  time  to  live  limits  the  amount  of  time  any 
datagram  packet  is  alive  on  a  network.  The  time  to  live  value  will  decrement  at  each 
router.  If  it  reaches  zero  before  it  reaches  its  destination  it  is  discarded.  The  header 
checksum  field  is  a  checksum  value  of  the  header.  It  must  be  recalculated  at  every 
router  due  to  the  time  to  live  function  and  when  the  packets  must  be  fragmented. 

With  the  options  described  above  IP  version  4  has  proven  very  reliable  for  data 
transfer  up  through  the  1980s  and  1990s  yet  IPv4  has  become  less  efficient  as  the 
internet  has  continued  to  expand  into  the  new  century.  IPv4  was  not  designed  to 
manage  the  extent  of  nodes  it  supports  today.  Up  through  the  past  few  years  use  of  the 
VoIP  convention  has  greatly  increased.  As  the  personal  computer  market  has  expanded 
in  the  past  decade  so  has  the  requirement  for  a  larger  internetworking  solution  for 
TCP/IP.  Over  the  past  5  years  there  has  been  efforts  to  create  a  next  generation 
TCP/IP  to  incorporate  requirements  of  today's  internet.  IPv6  offers  many  more 
distinctive  attributes,  specifically  in  the  area  of  voice/video  over  the  internet. 

B.  IPV6  ENHANCEMENTS  FOR  PACKET  TRANSFER  WITH  VoIP 

The  actual  operation  process  of  IPv6  is  the  same  as  IPv4.  In  order  to  phase  IPv6 
into  operation  IPv6  can  be  utilized  within  an  IPv4  environment  yet  with  a  degeneration  of 
full  IPv6  functionality.  IP  with  version  6  will  sustain  voice  and  video  over  the  internet  in 
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several  ways  that  version  4  does  not.  In  order  to  anticipate  an  expanding  internet  IPv6 
has  included  simplification  of  the  IP  header  to  realize  increased  operability  from  the 
internet.  The  IPv6  simplified  header  allows  more  functionality  with  an  overall  smaller 
overhead  requirement  for  processing.  The  new  header  fields  available  with  IPv6  assist 
by  prioritizing  packets  and  associating  packets  within  a  flow  for  site-to-site  message 
traffic.  Finally,  the  difference  in  fragmentation  handling  between  IPv4  and  IPv6  also 
assists  with  voice  and  video  IP  messaging. 

1.  Simplified  Header 

IPv4  utilizes  standard  header  fields  that  offer  the  consistent  options  described 
above.  All  routers  and  hosts  along  the  path  as  well  as  the  destination  host  still  must 
process  all  the  fields  within  the  IPv4  header  whether  or  not  they  are  utilized,  such  as  with 
the  fragment  offset  even  if  the  packet  is  not  a  fragment.  IPv6  utilizes  a  slightly  different 
model  for  its  datagram  header  and  IP  processing.  The  IPv6  header  has  fewer  fields 
than  the  IPv4  header.  Figure  3-2  depicts  the  fields  required  for  an  IPv6  datagram 
packet.  Another  important  difference  is  that  the  IPv6  header  is  a  standard  size.  This 
precludes  the  requirement  for  a  header  length  field  in  the  IPv6  header  as  with  the  IPv4 
header. 

IPv6  utilizes  “extension”  headers  for  each  datagram  packet  that  requires  special 
options.  These  extension  headers  are  not  actually  part  of  the  IPv6  header.  The  “Next 
Header”  field  delineates  the  next  header  for  each  IPv6  datagram.  The  extension  header 
resides  within  the  datagram  packet  before  payload  portion  of  the  datagram  and  is  not 
part  of  the  header  itself.  Figure  3-3  illustrates  the  extension  header  concept  and  Figure 
3-4  shows  the  standard  extension  header  format.  The  IPv6  specification  (RFC  2460) 
recommends  that  the  next  headers  be  placed  in  a  specific  order.  The  required  order  is 
IPv6  header,  hop-by-hop  extension  header,  destination  options  header,  routing  header, 
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fragment  header,  authentication  header,  encapsulation  security  payload  header, 
destination  options  header,  and  finally  upper  layer  header.  Thus,  when  there  are  no 
additional  IP  options  required  the  next  header  designated  would  be  the  higher  protocol 
such  as  TCP  or  UDP.  The  destination  options  headers  and  routing  header  deal  with 
source  routing,  which  are  IPv6  options  outside  the  scope  of  this  thesis  and  not  discussed 
further. 
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Figure  3-2  IPv6  Datagram  Packet  Header  Format 

IPv6  has  two  categories  of  extension  headers.  One  category  requires 

processing  by  every  node  between  the  source  and  destination  while  the  other  category 
requires  processing  by  the  destination  host  only.  Figure  3-3  shows  the  difference 
between  these  two  type  headers  by  showing  node  perception  along  the  IPv6  datagram 
path.  The  “hop  by  hop”  extension  headers  are  the  only  extension  headers  that  are 
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processed  by  each  intermediate  node  as  the  packet  transverses  the  internet.  The  hop- 
by-hop  extension  header  is  the  first  next  header  that  follows  directly  after  the  IPv6 
header.  At  this  time  the  only  two  options  specified  for  hop-by-hop  are  Jumbo  payload 
option  and  the  router  alert  option.  [Ref  23:p.  83]  Neither  of  these  existing  options 
improves  VoIP  or  video  teleconferencing  quality. 
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Figure  3-4  Standard  hop-by-hop  /  destination  Extension  Header  Format 


No  other  extension  headers,  including  higher  level  protocols,  are  processed  by 
intermediate  nodes.  Instead  the  remaining  extension  headers  are  processed  only  at  the 
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destination  node.  At  the  destination  node  all  extension  headers  are  processed  one  by 
one.  After  all  of  the  extension  headers  have  been  processed  for  an  individual  packet  the 
next  header  field  will  show  the  next  header  protocol,  such  as  TCP  or  UDP  required  for 
processing  the  packet. 

2.  Fragmentation 

The  concept  of  datagram  packet  fragmentation  for  IPv6  is  managed 
fundamentally  different  than  for  IPv4.  IPv4  packets  can  be  fragmented  at  any 
intermediate  node  along  the  path  that  does  not  allow  packets  as  large  as  the  original 
packet  size.  IPv6  allows  fragmentation  only  at  the  originating  or  source  node.  The 
fragmentation  option  is  utilized  as  an  extension  header  with  its  own  format. 

Figure  3-5  portrays  the  fragmentation  header  format.  The  next  header  field  (8 
bits)  is  the  format  of  the  subsequent  header  field.  The  next  field  (8  bits)  of  the 
fragmentation  header  is  reserved  for  future  use.  The  fragment  offset  (1 3  bits)  value  tells 
the  destination  numbered  in  8-bit  segments  where  this  portion  fits  within  the 
fragmentable  portion  of  the  packets. .  The  fragmentable  portion  includes  only  the  payload 
and  extension  headers  that  are  to  be  processed  when  the  packet  has  arrived  at  its  final 
destination.  The  next  field  is  another  field  reserved  (2  bits)  for  future  use.  The  next  field 
is  the  M  flag  which  when  the  value  is  1  indicates  another  fragment  is  forthcoming,  a  zero 
indicates  this  is  the  last  fragment.  The  final  identification  field  holds  a  32-bit  identifier 
that  is  intended  to  uniquely  identify  any  packet  sent  recently. 

As  described  above  this  principle  simplifies  the  header  while  it  greatly  reduces 
overhead  of  router  processing.  Since  fragmentation  is  not  a  hop-by-hop  extension 
header  only  the  source  and  destination  node  ever  process  the  fragmentation  information 
located  within  the  payload  of  the  packet.  Figure  3-3  portrays  this.  It  must  be  noted  that 
since  datagram  packets  can  not  be  fragmented  along  the  way  when  a  node  cannot 
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forward  the  packet  due  to  packet  size  limitation  an  error  message  must  be  sent  back 
utilizing  ICMPv6. 
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Figure  3-5  Fragmentation  Header  Format 

In  order  to  prevent  error  messages  the  IPv6  specification  recommends  all  nodes 

implement  path  MTU  discovery  and  send  packets  within  the  size  allowed  per  the  path 
utilized  [Ref  23:p.  124].  Simply  put,  the  MTU  discovery  is  a  process  where  the 
originating  node  sends  a  packet  to  the  destination.  Along  the  path  it  checks  the  largest 
allowable  MTU  size  of  each  node  and  delivers  this  information  back  to  the  originating 
node  prior  to  releasing  any  datagram  packets  to  the  destination.  The  packets  now  sent 
from  source  to  destination  will  be  no  larger  than  the  intermediate  nodes  with  the  lowest 
capability  of  MTU  size  discovered  through  the  MTU  discovery  process.  As  described 
above  ICMPv6  will  be  utilized  if  instantaneous  changes  occur  within  the  network  path  to 
preclude  usage  of  the  MTU  discovery  path. 

3.  Added  Functionality  within  the  Header  Fields 

The  IPv6  header  contains  several  fields  that  are  not  found  within  the  IPv4 
header.  The  functionality  of  these  additional  fields  expands  the  usefulness  found  within 
IPv4  headers.  These  added  capabilities  directly  support  the  extra  requirements  thrust 
upon  the  internet  due  to  VoIP.  The  traffic  class  and  flow  label  fields  within  the  IPv6 
header  prioritize  packets  and  control  delivery  paths  in  an  attempt  to  improve  upon  IPv4 
technology.  Figure  3-2  illustrates  this  format  of  the  IPv6  header. 
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The  traffic  class  field  is  an  8-bit  value.  The  traffic  class  field  replaces  the  type  of 
service  field  found  in  IPv4  with  added  functionality.  Presently  the  traffic  class  is  marked 
to  be  a  priority  field  in  which  one  of  16  different  priority  classes  could  be  specified  for 
each  datagram  packet.  The  traffic  class  is  identified  by  the  originating  source  and  can 
be  changed  by  intermediate  routers  that  support  the  traffic  class  functionality.  All  other 
routers  would  merely  pass  on  the  existing  value  within  this  field.  The  actual  values  to  be 
utilized  within  the  traffic  class  field  are  presently  undetermined.  It  shows  great  potential 
for  voice  and  video  transmission  service  though.  It  is  not  decided  as  of  yet,  but  the  field 
would  probably  be  set  by  upper-layer  protocols,  such  as  the  voice  or  video  applications. 
[Ref  23:p.  79] 

The  IPv4  protocol  permits  all  datagram  packets  to  find  their  own  individual  paths 
from  source  to  destination.  In  the  past  this  has  been  the  beauty  of  internet  functionality. 
This  IP  technology  allowed  for  instantaneous  changes  within  the  existing  worldwide 
architectures;  no  individual  computer  would  prevent  the  populace  from  receiving  and 
sending  message  traffic  via  the  internet.  Yet,  in  order  for  each  packet  to  find  its  own 
path  each  intermediate  node  must  process  the  packet's  entire  header  to  establish  the 
route  path  for  next  node  delivery.  Time  requirements  for  the  transmission  of  entire 
groups  of  datagram  packets  due  to  VoIP  or  video  teleconferencing  demand  an  evolution 
of  the  IP  technology.  Taking  this  into  account  IPv6  offers  just  such  an  evolutionary 
change. 

IPv6  appends  the  individualistic  packet  delivery  process  of  IP  with  a  header  field 
identified  as  the  flow  label.  The  flow  label  header  field  utilizes  a  20-bit  value  to  establish 
a  numerical  system  associating  each  datagram  packet  of  the  same  flow  with  a  same 
flow  label  value.  All  packets  with  a  value  in  the  flow  label  field  require  special  handling. 
Once  the  processing  node  determines  the  packet  is  of  the  same  flow  as  a  previous 
packet  it  passes  the  packet  along  to  the  same  node  without  the  additional  requirement  to 
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process  the  remaining  portion  of  the  datagram  packet  header  for  next  node  delivery 
information.  The  flow  concept  greatly  strengthens  the  IP  configuration  by  reducing  the 
overhead  associated  with  individual  processing  requirements  as  found  in  IPv4.  [Ref 
23:p.  78] 

C.  IPV6  SECURITY  CAPABILITY  UTILIZING  EXTENSION  HEADERS 

Security  is  becoming  an  important  requirement  for  internet  communications.  It  is 
imperative  to  individuals  and  businesses  alike  that  internet  traffic  is  safely  delivered  to  its 
destination.  Often  added  demands  on  internet  traffic  include  an  assurance  of  the  traffic 
source  to  the  destination  host  and  safeguarding  of  the  information  contained  within  the 
transferred  data  throughout  its  transit  to  the  destination  host.  Internet  protocol  security  is 
examined  here  as  a  possible  addition  to  the  home  communicator. 

IPv4  originally  developed  as  a  research  mechanism  between  government, 
education,  and  business.  It  then  evolved  into  the  production  package  the  world  utilizes 
today.  Security  although  an  important  aspect  of  point  to  point  communication  was  not 
initially  built  into  the  IPv4  package.  IPsec  was  established  through  RFC  1 825  and 
updated  by  RFC  2401  to  incorporate  security  into  the  existing  IP  architecture.  It  must  be 
noted  that  IPsec  is  not  joined  to  any  specific  IP  version  and  can  be  incorporated  into 
both  IPv4  and  IPv6. 

The  two  means  of  security  for  IP  technology  are  the  Authentication  Header  and 
the  Encapsulation  Security  Header.  They  can  be  utilized  individually  or  together.  Each 
supports  transport  or  tunnel  modes  of  operation.  Transport  mode  simply  put  is  a  host  to 
host  security  connection.  The  tunnel  mode  involves  a  security  gateway  design.  Tunnel 
mode  can  be  utilized  with  a  host  node  to  a  security  gateway  and  vice  versa  as  well  as 
security  gateway  to  security  gateway.  If  a  security  gateway  is  operating  as  a  host  it  can 
utilize  the  transport  mode  but  only  under  host  status.  Authentication  and  Encapsulation 
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Security  are  known  as  one-way  protocols.  Both  directions  must  implement  these 
protocols  in  order  to  have  a  two-way  functionality.  [Ref  23:p.  142] 

1 .  Authentication  Header 

The  Authentication  Header  (AH)  allows  the  source  node  to  digitally  sign  outgoing 
packets.  There  is  no  encryption  capability  with  the  authentication  header.  "The 
Authentication  Header  provides  connectionless  integrity,  data  origin  authentication,  and 
an  optional  anti-replay  service."  [Ref  24:p.  231]  In  other  words  by  utilizing  the  AH  the 
receiver  can  be  confident  that  the  information  transmitted  is  what  was  intended  to  be 
sent  and  that  the  sender  is  who  really  transmitted  the  information.  Replay  attacks  are 
third  party  intrusions  where  information  intercepted  is  bombarded  to  the  receiver  in 
hopes  of  overwhelming  the  receiving  system.  The  transmitting  and  receiving  hosts  must 
utilize  the  anti-replay  service  in  order  for  it  to  be  effective.  The  transmitting  host 
numbers  each  packet  with  a  sequence  number.  The  receiving  host  must  check  the 
sequence  numbers  to  be  effective. 

The  authentication  header  is  utilized  differently  for  transport  and  tunnel  modes. 
With  the  transport  mode  the  authentication  header  comes  before  the  next  level  protocol 
header  but  after  the  IP  header  and  options  associated  with  it.  It  protects  higher  level 
protocols  as  well  as  portions  of  the  IP  header.  IPv4  places  the  authentication  header 
after  the  original  IP  header  with  all  its  options.  The  IPv6  authentication  header  is  placed 
after  hop-by-hop,  routing,  and  fragmentation  extension  headers.  The  protection  allotted 
by  the  authentication  in  transport  mode  extends  to  the  payload  of  the  original  IP 
datagram  and  only  parts  of  the  IP  header  that  do  not  change  as  they  transverse  the 
internet. 

In  the  authentication  tunnel  mode  the  original  IP  header  is  encapsulated  within 
the  authentication  header  placing  it  directly  behind  the  authentication  header  itself.  In 
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the  case  of  IPv4  the  authentication  header  comes  directly  after  the  new  IP  header  and 
any  possible  options  required  with  the  new  IP  header.  With  IPv6  the  authentication 
header  is  an  extension  header  of  the  new  IP  header.  The  authentication  header,  when 
utilized  in  tunneling  mode  protects  the  original  IP  datagram  in  its  entirety. 

Figure  3-6  displays  the  authentication  header  format.  The  three  most  significant 
fields  within  the  authentication  header  are  Security  Parameter  Index  (SPI),  Sequence 
Number,  and  Authentication  Data.  The  security  parameter  index  is  a  32-bit,  arbitrary 
value  that  uniquely  identifies  the  security  association  between  the  authentication  header 
and  the  destination  address.  RFC  2401  defines  a  security  association  as  a  simplex  (uni¬ 
directional)  logical  connection,  created  for  security  purposes.  There  would  be  a  different 
security  association  for  authentication  header  and  for  Encapsulation  Security  Payload 
header  as  described  in  the  next  section.  The  sequence  number  is  a  mandatory  counter. 
The  sequence  number  increments  with  every  datagram  transmitted.  If  the  receiving  host 
or  gateway  monitors  the  SPI  and  sequence  number,  duplicates  can  be  discarded 
preventing  replay  attacks.  The  authentication  data  field  contains  the  Integrity  Check 
Value  (ICV).  The  security  association  specifies  the  authentication  algorithm  to  be 
employed  for  the  ICV  computation.  The  ICV  is  computed  from  IP  header  fields  that  are 
immutable  (or  predictable  at  destination),  the  AH  header  (with  the  Authentication  Data 
figured  as  zero),  and  upper  level  protocol  data. 

2.  Encapsulation  Security  Payload 

The  Encapsulation  Security  Payload  (ESP)  provides  authentication  as  well  as 
encryption  to  safeguard  the  payload.  It  may  be  used  in  conjunction  with  the 
authentication  header  or  alone.  "ESP  is  used  to  provide  confidentiality,  data  origin 
authentication,  connectionless  integrity,  an  anti-replay  service  (a  form  of  partial 
sequence  integrity),  and  limited  traffic  flow  confidentiality."  [Ref  25]  Simply  put  ESP 
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offers  encryption  and  limited  traffic  flow  confidentiality  in  addition  to  the  authentication 
header.  Yet,  a  point  to  be  made  is  that  the  authentication  found  with  ESP  is  not  as 
extensive  as  found  with  the  authentication  header.  ESP  can  be  utilized  with  only 
encryption,  but  it  is  necessary  to  include  authentication  either  with  the  ESP  protocol  or  in 
conjunction  with  the  authentication  header.  In  order  to  employ  the  limited  traffic  flow 
confidentiality  function  of  ESP  it  must  be  operated  in  the  tunnel  mode. 
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Figure  3-6  Authentication  Header  Format 

The  ESP  header  is  utilized  differently  for  transport  and  tunnel  modes.  With  the 
transport  mode  the  ESP  header  comes  before  the  next  level  protocol  header  but  after 
the  IP  header  and  options  associated  with  it.  Unlike  the  authentication  header  in 
transport  mode,  when  the  ESP  header  is  utilized  in  transport  mode  it  does  not  protect 
any  portion  of  the  IP  header,  only  upper  layer  protocols.  IPv4  places  the  ESP  header 
after  the  original  IP  header  with  all  its  options.  The  IPv6  ESP  header  is  placed  after  hop 
by  hop,  routing,  and  fragmentation  extension  headers.  The  ESP  header  can  be  placed 
either  before  or  after  the  destination  extension  headers,  but  it  only  protects  the  headers 
that  follow  it. 

In  the  ESP  tunnel  mode  the  original  IP  header  is  encapsulated  within  the  ESP 
header  placing  it  directly  behind  the  ESP  header  itself.  In  the  case  of  IPv4  the  ESP 
header  comes  directly  after  the  new  IP  header  and  any  possible  options  required  with 
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the  new  IP  header.  With  IPv6  the  ESP  header  is  an  extension  header  of  the  new  IP 
header.  The  ESP  header,  when  utilized  in  tunneling  mode  protects  the  original  IP 
datagram  in  its  entirety.  The  ESP  header  and  its  contents  are  authenticated.  The 
contents  minus  the  ESP  header  are  encrypted. 
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|  Sequence  Number  Field  | 

I  I 

|  Payload  Data  (variable)  | 

I  i 

j  |  Padding  (0-255  octets)  | 

|  |  Pad  Length  |  Next  Header  | 

+-+-+-+-+-+-+-+-+-+-+-+--F-+-+-+-+-+-+ 

I  I 

|  Authentication  Data  (variable)  I 

i  i 

+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+ 

Figure  3*7  Encapsulation  Security  Payload  Header  Format 

Figure  3-7  illustrates  the  ESP  header  format.  The  ESP  Header  fields  are 
Security  Parameters  Index,  Sequence  Number,  Payload  Data,  Padding,  Pad  Length, 
Next  Header,  Authentication  Data.  The  first  two  and  the  last  one  provide  the 
authentication  portion  of  the  ESP  similar  to  what  was  described  above  in  the 
Authentication  Header.  This  is  an  optional  function  within  the  ESP  header.  The 
remaining  four  fields  correspond  to  confidentiality  within  the  ESP  header.  The  Payload 
Data  is  the  information  being  encapsulated  by  the  ESP  header.  Its  format  corresponds 
to  the  information  found  within  the  Next  Header  field.  The  Padding  and  Pad  Length 
relates  to  the  specific  encryption  information  required  for  extracting  the  data.  The  actual 
information  in  these  fields  depends  upon  the  Security  Association  selected. 
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D.  IPV6  ADDRESS  TO  PHONE  NUMBER  SCHEME 


One  of  the  foremost  reasons  the  business  world  is  looking  to  replace  and 
upgrade  IPv4  is  the  decreasing  number  of  available  IPv4  addresses.  IPv6  offers  a  much 
larger  quantity  of  possible  IP  addresses  simply  by  quadrupling  the  IP  address  space  to 
128  bits.  Another  aspect  of  IPv6  is  that  it  completely  alters  the  present  method  of 
address  allocation  and  distribution.  The  next  section  describes  the  address  allocation  of 
IPv6  and  the  following  section  describes  how  the  new  format  could  be  used  in  such  a 
way  to  approach  the  telephone  system  in  use  today. 

1 .  Address  Allocation/Network  Topology 

IPv4  addressing  notation  is  represented  as  a  set  of  four  two-digit  hexadecimal 
integers  separated  by  periods  or  dots.  Figure  3-8a  displays  the  IPv4  addressing 
representation.  The  hexadecimal  values  are  actually  written  in  decimal  format.  IPv6 
addresses  are  represented  by  a  set  of  eight  four-digit  hexadecimal  integers  separated  by 
colons.  Figure  3-8b  shows  the  IPv6  addressing  representation.  In  order  to  phase  in 
IPv6  into  the  worldwide  network  there  is  a  third  format  that  combines  IPv4  and  IPv6. 

This  format  is  represented  by  a  set  of  six  four-digit  hexadecimal  integers  separated  by 
colons  followed  by  four  two-digit  hexadecimal  integers  shown  in  decimal  format  and 
separated  by  periods  or  dots.  A  colon  separates  the  first  six  from  the  last  four  values. 
Figure  3-8c  describes  the  IPv4/IPv6  interim  addressing  representation.  Only  existing 
IPv4  addresses  being  utilized  within  an  IPv6  environment  require  this  format.  The  first 
six  values  would  be  0's  and  the  last  four  values  would  be  the  actual  IPv4  address. 

Subnet  masking  is  shown  by  a  backslash  with  the  number  of  bits  that  refers  to  the  prefix. 
[Ref  23:pp.  91-91] 
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IPv6  supports  three  different  types  of  addresses,  unicast,  multicast,  and  anycast. 
Broadcast  addresses  found  with  IPv4  are  not  available  with  IPv6.  IPv6  addresses  are 
hierarchically  designed  to  promote  internet  routing.  The  IPv6  format  supports  private 
site  addresses  for  organizational  use.  Also,  there  are  multicast  addresses  for  both  local 
and  global  usage. 

Format  Example 

a.  d.d.d.d  128.253.36.88 

(2  digit  Hex  equals  0-255  possible  decimal  values) 

b.  hhhh:hhhh:hhhh:hhhh:hhhh:hhhh:hhhh:hhhh  FEDC:BA98:0:0:0:0:7654:3210 

c.  hhhh:hhhh:hhhh:hhhh:hhhh:hhhh:d.d.d.d  0:0:0:0:0:0:128.253.36.88 

Figure  3-8  Addressing  Representation 

The  aggregatable  global  unicast  address  is  given  a  large  block  of  addresses. 

Each  unicast  address  identifies  a  single  network  interface.  If  a  node  has  more  than  one 

network  interface  it  will  have  more  than  one  IPv6  unicast  address.  No  two  nodes  can 

share  a  unicast  address.  Internet  unicast  addresses  have  been  given  the  hierarchical 

structure  to  facilitate  network  routing. 

Of  the  entire  IPv6  unicast  address  the  first  48-bits  make  up  the  public  portion. 
The  format  of  the  public  portion  begins  with  the  format  prefix.  Figure  3-9  displays  the 
format  scheme  for  IPv6  unicast  addressing.  Currently  the  only  three-bit  prefix  code  used 
is  "001."  010,  011, 100, 101,  and  110  are  presently  unassigned  and  may  later  be 
utilized  for  unicast  addressing.  000  and  111  are  utilized  for  other  address  formats.  The 
next  block  is  the  TLA  ID  or  top-level  aggregation  identifier.  It  is  a  13-bit  block  that  is 
used  for  the  highest-level  service  providers.  The  next  field  is  an  8-bit  field  reserved  to 
expand  either  the  TLA  ID  or  the  next  field  known  as  the  NLA  ID  or  the  next-level 
aggregation  identifier.  The  NLA  ID  is  a  24-bit  field  to  be  utilized  by  the  top-level  service 
to  identify  its  subscribers.  This  can  be  used  to  create  a  subhierarchy  or  to  identify 
smaller  service  providers  attached  to  the  larger  provider. 
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Figure  3-9  Unicast  Address  format 


The  last  80-bits  of  the  IPv6  unicast  address  belongs  to  the  subscriber  [Ref  22:p. 
799].  The  SLA  ID  or  the  sit-level  aggregation  identifier  is  16  bits.  It  can  be  used  to 
number  subnets  or  to  create  a  subhierarchy  of  areas  and  subnets.  The  final  field  is  the 
Interface  Identifier.  Here  64-bits  are  used  to  identify  the  individual  device  interface.  The 
interface  identifiers  are  based  on  the  IEEE  EUI-64  format.  This  format  uses  the  existing 
MAC  addresses  to  create  the  interface  identifier.  The  interface  identifiers  can  be  used  to 
globally  address  each  and  every  network  interface  uniquely. 

Multicast  addressing  is  similar  to  broadcast  technology.  The  major  difference  is 
that  IPv6  multicast  packets  are  only  delivered  to  the  nodes  that  specifically  subscribe  to 
a  particular  multicast.  The  format  of  a  multicast  packet  is  very  rigid.  Figure  3-10 
displays  the  IPv6  multicast  addressing  scheme.  Multicast  addresses  can  only  be  used 
as  destination  addresses,  never  source  addresses.  The  first  8  bits  designates  a 
multicast  address  by  holding  all  1's.  The  next  four  bits  are  individual  flags.  Only  the 
fourth  is  presently  assigned.  If  this  is  1  it  designates  the  multicast  as  permanent 
multicast  address,  a  0  designates  it  as  a  transient  or  temporary  address.  The  next  four 
bits  describe  the  scope  of  the  multicast  group.  In  other  words  the  value  of  the  scope 
indicates  whether  the  multicast  group  can  include  only  nodes  on  the  same  local  network, 
same  site,  same  organization,  or  anywhere  within  the  IPv6  global  address  space.  The 
final  112  bits  designate  the  group  identification.  Two  different  group  id's  can  be  the 
same  depending  on  the  scope  and  the  designation  of  transient  or  permanent  multicast 
address. 
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Figure  3-10  Multicast  Address  format 


The  anycast  address  for  IPv6  is  similar  to  the  multicast.  The  similarity  is  that  like 
a  multicast  address  the  anycast  address  corresponds  to  more  than  one  node.  One 
difference  is  within  the  requirement  of  who  exactly  receives  the  multicast  packet.  All 
nodes  that  subscribe  to  the  particular  multicast  receive  the  multicast  packet  but  an 
anycast  packet  only  has  to  reach  one  of  the  nodes  designated  by  the  particular  anycast. 
Another  difference  is  that  the  address  format  is  consistent  with  a  unicast  address  rather 
than  the  multicast  address  format.  Because  the  anycast  addresses  are  unicast 
addresses,  members  of  an  anycast  address  must  each  be  explicitly  configured  to 
recognize  that  address  as  an  anycast  address.  [Ref  23:p.  109] 

Finally,  for  edification  there  are  other  IPv6  addresses  that  are  utilized  for  testing 
and  setup  of  networks.  One  such  address  is  the  unspecified  address  or  all-zeros 
address.  Computers  that  have  no  valid  address  such  as  a  new  computer  booting  up  on 
an  existing  network  utilize  the  unspecified  address.  There  is  also  a  loopback  address  in 
IPv6.  The  loopback  is  a  testing  address  only  and  is  internally  used  by  the  node  by 
sending  a  packet  to  immediately  reenter  the  node's  IP  stack  but  to  appear  as  if  it  came 
from  an  outside  source. 

2.  Regionalize  the  IP  Addresses 

The  telephone  identification  scheme  is  hierarchical  by  location.  When  dialing 
within  the  same  area  code  one  need  only  dial  the  last  7  digits,  yet  if  dialing  to  another 
country  the  country  code  must  be  dialed  before  the  area  code  and  local  number. 

Looking  at  IPv6  the  unicast  address  is  the  point-to-point  addressing  scheme  that  would 
be  utilized  for  all  data  transfer  to  and  from  the  home  communication  system. 
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The  unicast  addressing  system  of  IPv6  is  also  hierarchical  in  nature  but  it  is 
hierarchical  by  top-level  service  providers  not  location.  One  of  the  major  problems  that 
had  developed  over  time  with  IPv4  addressing  was  an  inability  to  support  internal 
company  networking  growth.  Table  3-1  shows  the  address  class  characteristics  of  IPv4. 
If  a  company  had  outgrown  its  class  C  addressing  scheme  the  additional  addressing 
fields  received  through  ARIN  (The  American  Registry  for  Internet  Numbers),  RIPE  (The 
Reseaux  IP  Europeens),  or  APNIC  (The  Asia-Pacific  Network  Information  Center)  would 
not  be  numerically  close  to  the  existing  values.  Also,  it  turned  out  that  very  few 
organizations  could  actually  utilize  a  class  A  address.  This  was  causing  a  waste  of 
address  space.  Today  many  organizations  are  utilizing  several  class  C  addresses 
together  to  because  their  organization  is  too  small  for  class  B  buy  too  large  for  a  class  C 
address.  IPv6's  addressing  scheme  has  taken  this  into  consideration  and  is  based  on 
business'  internal  requirements  for  addressing  and  company  growth. 

Length  of  Number  of 

Class  Network  Address  First  Number  Local  Addresses 

A  1  byte  0-127  16,777,216 

B  2  bytes  128-191  65,536 

C  3  bytes  192-223  256 

Table  3-1  Address  Class  Characteristics  for  IPv4 

As  described  above  the  first  three  bits  for  a  unicast  address  is  001.  The  next 
field  is  the  TLA  ID  is  13  bits  long  and  holds  a  possibility  of  8,192  different  values.  The 
TLA  ID  is  given  to  top-level  service  providers.  The  top-level  service  providers  will 
include  government  and  commercial  providers.  This  is  against  the  basic  premise  of  the 
phone  hierarchy  in  the  sense  that  the  country  telephone  codes  and  area  telephone 
codes  are  the  same  regardless  of  who  the  service  provider  is.  Here  the  service  provider 
will  hold  the  highest  order  of  the  numbering  criteria.  In  order  to  offer  a  true  hierarchical 
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system  such  as  the  telephone  system  the  top  level  service  providers  would  have  to 
maintain  the  rights  to  certain  wide  area  locations  within  the  world.  This  is  not  feasible. 

Since  it  is  not  possible  to  support  an  overarching  hierarchical  solution  as  found 
with  the  existing  telephone  system  a  next  option  is  to  investigate  the  ability  to  offer 
hierarchical  capabilities  within  the  top-level  service  provider  down  to  the  customer.  The 
NLA  ID  is  24  bits  long  and  is  the  next-level  aggregation.  The  site  and/or  service  provider 
utilizes  the  NLA  ID  to  further  break  down  the  LAN  architecture  within  an  organization.  It 
has  the  possibility  of  16,777,216  values.  The  SLA  ID  is  16  bits  long  and  is  a  site  level 
aggregation.  It  has  a  possibility  of  65,536  values  to  allow  companies  the  ability  to 
manage  their  own  hierarchical  addresses. 

Something  worth  noting  is  that  the  home  communicator  will  be  utilized  within 
households  rather  than  companies.  The  requirement  for  internal  routing  within  a 
household  is  much  less  than  business  needs.  The  internal  routing  functionality  for 
businesses  that  is  built  into  IPv6  could  be  used  by  the  internet  service  provider.  In 
other  words,  the  top-level  service  provider  could  utilize  the  NLA  ID  and  SLA  ID  together 
to  offer  a  greater  footprint  of  service  to  homes  with  home  communicators.  Together  the 
NLA  ID  and  SLA  ID  are  40  bits  offering  a  total  of  1 ,099,51 1 ,627,776  values  together. 

The  reserve  field  in  between  the  TLA  ID  and  NLA  ID  when  used  will  open  up  the  ability 
to  offer  more  households  for  each  of  top-level  service  providers.  The  NLA  could  be 
utilized  at  the  country,  state,  and  even  county  levels.  The  SLA  ID  could  be  utilized  at  the 
neighborhood  for  large  cities  or  town  level  for  the  smaller  towns.  The  Interface  ID  is  a 
64-bit  value  based  on  the  IEEE  EUI-64  interface  ID  and  will  easily  identify  the  different 
telephones  within  one  household  as  each  will  require  a  separate  interface  to  the 
network.  The  NLA  and  SLA  ID's  overall  could  be  segregated  out  by  a  populous  mapping 
structure  throughout  the  world  to  offer  a  similar  hierarchical  scheme  to  the  telephone 
numbering  scheme. 


49 


Unlike  the  telephone  system  where  dialing  local  numbers  requires  fewer  digits 
than  long  distance  the  IP  technology  requires  all  digits  of  the  IP  address  to  route.  This 
telephone  hierarchical  scheme  could  be  approached  by  additional  VoIP  software.  In 
order  to  make  a  long  distance  telephone  call  one  must  dial  1  first.  This  alerts  the 
telephone  switch  to  the  fact  it  is  a  long  distance  phone  call.  The  same  could  be 
programmed  into  the  software  that  changes  the  telephone  input  into  the  VoIP.  Yet, 
because  the  highest  level  of  IPv6  addressing  is  the  top-level  service  provider  there  will 
always  be  a  requirement  to  include  the  top-level  addressing  code  when  making  a  call. 

The  bottom  line  is  that  IPv6  will  allow  regionalization  of  IP  addresses  that 
approach  the  existing  scheme  found  with  telephone  numbers.  Yet  IPv6  will  not  equal  or 
surpass  the  versatile  hierarchy  technology  found  with  the  telephone  service  unless  IANA 
modifies  the  proposed  format  to  offer  more  of  a  regionalized  format.  The  presently 
projected  organizational  format  cannot  be  manipulated  to  support  true  telephone 
scheme  technology  as  long  as  it  requires  the  top-level  service  provider  at  the  top  of  the 
IP  addressing  scheme. 

E.  REQUIREMENTS  TO  INTEGRATE  IPv6  INTO  LINUX 

Linux  unlike  other  operating  system  software  utilizes  the  talents  of  interested 
participants  throughout  the  world  to  upgrade  and  enhance  the  Linux  kernel  due  to  the 
GNU  General  Public  License  it  is  captured  under.  The  integration  of  IPv6  into  the  Linux 
kernel  is  no  different.  In  other  words  consumers  do  not  have  to  wait  for  the  parent 
company  to  establish  a  new  feature  such  as  IPv6  to  be  able  to  utilize  it.  Instead, 
individuals  who  have  developed  modules  for  IPv6  functionality  within  the  Linux  kernel 
offer  them  freely  on  web  sites  for  open  testing  and  modification  by  other  interested 
participants. 
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In  order  to  offer  the  Linux  with  IPv6  functionality  the  existing  status  of  IPv6 
integration  into  the  released  Linux  kernels  must  be  validated  and  lacking  functionality 
must  be  written  into  code  and  tested.  Presently  the  latest  stable  release  of  the  Linux 
kernel  is  2.1.  This  version  as  well  as  the  next,  2.2,  has  IPv6  functionality  built  into  them. 
The  extent  of  the  Linux  IPv6  functionality  is  captured  on  the  web  site: 
http://www.bieringer.de/linux/IPv6/status/IPv6+Linux-status.html.  The  pages  of  this  web 
site  shows  that  certain  IPv6  requirements  are  in  process  of  being  developed  or  still 
missing. 

The  incomplete  or  missing  IPv6  functionality  required  in  Linux  to  support  a  home 
communicator  includes  flow  label  specific  routing  (in  process),  multicast  routing  (not 
implemented),  security  (in  process),  6  over  4  (in  process),  and  6  to  4  (missing).  The  flow 
label  specific  routing  of  IPv6  (described  in  section  IV.  B.  3)  will  strengthen  the  telephony 
capabilities  of  the  home  communicator.  Multicast  routing  will  expand  the  home 
communicator  telephone  functionality.  Multicast  will  allow  the  household  telephones  to 
operate  all  on  the  same  connection  or  independently  from  each  other.  The  security  with 
IPv6  is  additional  protection  for  point-to-point  communication.  The  IPsec,  authentication 
and/or  encryption,  will  supply  the  consumer  with  increased  safety  from  telephony  or  data 
transfer  interception  and  from  outside  attacks. 

The  functionalities  “6  over  4”  and  “6  to  4”  deal  specifically  with  the  timeframe  that 
IPv6  is  sharing  the  internet  with  IPv4.  Once  IPv4  has  been  replaced  completely  with 
IPv6  there  will  be  no  requirement  for  these  Linux  modules.  “6  over  4”  is  the  preparation 
for  an  IPv6  packet  to  be  sent  through  an  IPv4  network.  A  gateway  is  required  at  each 
end  to  support  conversion  from  IPv4  to  IPv6  and  vice  versa.  The  home  communicator 
internet  service  provider  would  support  this  capability  where  required.  “6  to  4”  is  the 
requirement  for  an  IPv6  packet  to  be  sent  on  an  IPv4  or  IPv6  network  to  an  IPv4  host. 
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Since  the  telephony  capability  for  the  home  communicator  is  directed  towards  other 
home  communicators  with  IPv6  or  to  standard  telephones  this  criteria  is  not  relevant. 

Finally  the  IPv6  addressing  scheme  must  be  examined  in  order  to  develop  a 
standardized  location  hierarchy  for  home  communicator  sales.  In  order  to  achieve  this  it 
is  important  to  take  into  consideration  the  footprint  of  expected  home  communicator 
sales.  Also,  future  sales  locations  must  be  taken  into  account  in  order  to  prevent  under 
utilization  of  IPv6  addressing  capabilities.  Once  a  standard  hierarchical  scheme  has 
been  developed  IP  addresses  can  be  distributed  to  customers  as  each  home 
communicator  is  sold. 

In  order  to  stand  up  the  home  communicator  system  with  IPv6  it  would  be 
necessary  to  have  a  stable  Linux  kernel  that  supported  the  functionality  described  here. 

If  this  functionality  were  not  found  within  Linux  stable  kernel  releases  or  separately  on 
Linux  support  web  sites  it  would  have  to  be  developed  prior  to  fielding  the  home 
communicator. 

F.  IPv6  VERSES  IPv4 

The  operational  IPv6  internet  is  known  as  the  6Bone.  "The  6bone  is  an 
experimental  worldwide  network  for  testing  interconnectivity  of  IPv6  implementations, 
checking  if  IPv6  really  works  well  or  not  in  actual  situation,  and  so  forth"  [Ref  26].  It  is 
expected  that  eventually  the  6Bone  will  become  the  world  wide  internet  and  IPv4  is 
ultimately  obsoleted.  In  the  interim  the  only  alternative  for  IPv6  specific  traffic  is  that  it 
be  tunneled  over  or  through  IPv4  networks.  A  problem  that  arises  with  this  is  that  most 
of  the  functionality  being  developed  into  the  IPv6  packet  is  lost  when  it  is  encapsulated 
within  IPv4  technology. 

Increasing  this  awkward  situation,  there  is  no  tangible  control  of  the  information 
technology  market  to  assure  a  speedy  conversion  to  IPv6.  Because  IPv6  continues  to 
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grow  at  a  slow  rate  the  requirement  to  tunnel  through  IPv4  remains  an  obligation  for 
anyone  designing  networking  hardware  and  software  today.  This  creates  is  a  problem 
from  either  standpoint  IPv4  or  IPv6.  All  IPv4  technology  will  have  to  be  replaced  with 
IPv6  equipment  when  IPv4  is  outmoded  from  the  internet.  Anything  designed  with  IPv6 
technology  must  wait  for  a  strong  IPv6  internet  to  fully  utilize  the  new  protocol 
functionality  to  their  complete  advantage.  It  is  basically  a  matter  of  time  before  the 
internet  becomes  IPv6  leaving  only  patches  of  outdated  IPv4  machinery. 

Another  related  issue  is  the  present  state  of  IPv6  technology.  Although  Request 
for  Comments  have  been  written  describing  the  utilization  of  specific  protocol  aspects 
there  is  still  a  large  portion  of  the  IPv6  protocol  that  has  as  of  yet  been  undetermined. 
Although  most  of  these  undetermined  options  are  minor  to  the  overall  IPv6  scheme 
some  may  cause  complete  redesign  of  existing  IP  software  to  be  implemented.  These 
issues  will  not  be  fully  solved  for  years  after  IPv6  becomes  prevalent  throughout  the 
internet. 

On  the  other  hand,  internet  technology  is  presently  available  that  utilizes  IPv6.  In 
1994  MCI  activated  a  project  known  as  vBNS  (very  high  performance  Backbone 
Network  Service).  The  project  was  an  internet  test  bed  sponsored  by  National  Science 
Foundation  for  university  and  business  research.  The  vBNS  now  connects  research 
institutions  as  well  as  research  institutions  that  are  served  by  other  networks.  The  vBNS 
began  utilizing  IPv6  over  its  backbone  ATM  technology  as  early  as  July  1998.  vBNS  has 
been  assigned  its  own  TLA  for  the  6bone.  Although  vBNS  is  offered  to  educational 
facilities  and  students  at  a  lower  rate  the  IPv6  functionality  present  in  the  MCI  WorldCom 
6bone  is  actually  available  to  all  MCI  WorldCom  vBNS  subscribers.  [Ref  27]  MCI 
WorldCom  has  intensions  of  expanding  the  6bone  capabilities.  In  late  May  2000 
WorldCom  announced  plans  to  develop  1 3  new  International  Data  Centers  across 
Europe  within  a  year.  [Ref  28] 


53 


G.  CHAPTER  SUMMARY  AND  IPv6  CONCLUSIONS 

This  chapter  began  with  a  brief  background  and  description  of  IPv4.  An 
explanation  of  the  IPv4  header  format  and  IPv4  options  presently  available  to  with  assist 
data  transfers  followed.  IPv6  was  then  described  in  relation  to  specific  enhancements 
that  have  been  incorporated  for  added  functionality  to  internet  protocol.  Such 
improvements  include  the  simplification  of  the  header  format,  additional  fragmentation 
operability  rules,  and  added  header  fields  that  reduce  the  overhead  of  IP  packets  during 
intermediate  node  packet  transfer  and  assist  with  overall  data  transfer.  IPsec  options 
are  then  described  from  both  the  IPv4  and  IPv6  viewpoints  respectively.  The  IPv6 
addressing  is  then  investigated  for  ability  to  approach  a  regionalized  numbering  scheme. 
Finally,  the  incorporation  of  IPv6  into  the  existing  Linux  kernel  is  described. 

IPv6  certainly  appears  to  be  the  next  generation  of  the  internet.  Not  only  does 
IPv6  support  the  larger  IP  addressing  requirements  facing  the  world  it  also  adds  a  level 
of  functionality  IPv4  does  not  approach.  When  IPv4  was  developed  there  was  no  way  to 
anticipate  the  audience  growing  to  the  household  market  or  the  IP  packet  data  growth  to 
voice  and  video.  Although  IPv4  can  carry  voice  effectively  today  the  growing  market  and 
requirements  placed  on  the  internet  will  undoubtedly  hamper  IPv4’s  usefulness  in  the 
future.  IPv4  is  becoming  archaic  with  packet  transfer  overhead  requirements  and  lack  of 
useful  IP  addresses.  IPv6  cuts  down  on  packet  transfer  overhead.  This  is  accomplished 
because  inherently  IPv6  requires  transfer  nodes  to  only  process  specific  information 
within  the  IP  header  and  not  the  entire  packet  and  IPv6  increases  the  IP  address  field 
enormously. 

As  stated  earlier,  it  is  often  not  any  of  the  governing  information  technology 
organizations  that  create  a  standard,  but  the  collective  customers’  actions  over  a  period 
of  time  that  creates  the  standards.  With  this  in  mind  there  are  no  guarantees  that  IPv6 
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will  emerge  as  a  self-sufficient  replacement  to  IPv4.  Even  though  MCI  WorldCom  has 
introduced  IPv6  within  its  network  and  begun  plans  to  expand  into  Europe  this  is  not  a 
guarantee  for  success.  Greg  Miller  of  NANOG  (Albuquerque  NM)  presented  a  brief 
entitled  “IPv6  on  vBNS+”  on  June  12,  2000,  found  on  the  website: 
http://www.vbns.net/presentations/NANOG_IPv6/tsld001.html.  The  closing  slide  was 
titled  “Why  are  we  doing  this?”  with  a  final  bullet  stating  “Unfortunately,  not  because 
customers  are  asking  us  for  it.”  Despite  this  opinion  it  is  the  authors  best  guess  that 
IPv6  will  successfully  replace  IPv4  almost  completely  within  the  next  5  years. 

Considering  the  assumption  IPv6  will  become  an  internet  standard  within  the 
next  5  years  it  is  important  that  the  initial  design  of  the  home  communicator  utilize  the 
IPv6  protocol.  A  majority  of  the  IPv6  functionality  has  already  been  developed  into  the 
Linux  kernel  2.1  and  next  release  2.2.  The  remaining  aspects  of  the  protocol  can  be 
developed  into  the  kernel  prior  to  completion  of  the  home  communicator.  There  no 
requirement  to  have  the  entire  IPv6  functionality  designed  in  prior  to  delivery  of  the  home 
communicator.  Since  a  high-level  design  requirement  is  5-year  life  span  the  major 
portions  required  for  IPv6  would  have  to  be  completed  prior  to  design  finalization  and 
product  production. 

It  must  be  noted  that  this  decision  to  utilize  IPv6  for  the  home  communicator  can 
be  handled  one  of  two  ways.  The  communicator  itself  could  be  configured  to  operate  as 
an  IPv4/IPv6  gateway.  The  home  communicator  would  build  the  data  into  an  IPv6 
packet  and  encapsulate  it  within  an  IPv4  datagram  packet  in  order  to  transverse  the  IPv4 
network  that  the  communicator  was  attached  to.  This  would  require  a  software  change 
when  the  communicator  was  connected  directly  to  an  IPv6  network  later  on.  The  second 
option  would  be  that  an  outside  infrastructure  would  be  designed  and  developed  by  the 
internet  service  provider  that  will  completely  support  IPv6  interconnectivity.  This 
infrastructure  would  have  to  be  extensive  to  accommodate  all  consumers  operating  the 
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home  communicator.  There  would  be  no  requirement  to  upgrade  software  later  since 
the  home  communicator  is  already  operating  with  IPv6  within  an  IPv6  environment. 
Obviously,  the  internet  architecture  within  any  given  location  or  region  would  direct  the 
version  of  IP  actually  utilized  for  a  given  home  communicator. 
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IV.  SPECIFICATION  AND  HIGH-LEVEL  DESIGN  OF  THE  HOME 
COMMUNICATOR 

This  chapter  describes  the  home  communicator.  The  first  section  lists  the  high- 
level  requirements.  The  second  section  lists  the  individual  functions  of  the  home 
communicator  and  how  they  will  be  achieved.  The  third  section  will  describe  what  the 
customer’s  view  of  the  home  communicator  will  be.  The  forth  section  lists  the  software 
high-level  design  of  the  home  communicator.  The  final  section  of  this  chapter  explains 
the  hardware  high-level  design  of  the  home  communicator. 

A.  HIGH  LEVEL  REQUIREMENTS 

High-level  functional  requirements  for  the  home  communicator  listed: 

•  Telephony:  The  home  communicator  package  must  contain  telephony 

capability. 

•  Television:  The  home  communicator  package  must  contain  television 

capability. 

•  E-mail:  The  home  communicator  package  must  contain  an  e-mail  service 

capability. 

•  Internet  Browsing:  The  home  communicator  package  must  contain  the 

capability  to  browse  the  world  internet. 

•  Chat:  The  home  communicator  package  must  contain  chat  capability  in 

conjunction  with  the  world  internet  browser. 

•  Simple  Text  Editor:  The  home  communicator  must  contain  a  simple  text  editor 

capability, 

•  Connector  to  peripheral  equipment:  The  home  communicator  must  contain 

the  capability  to  connect  additional  television(s),  telephone(s),  and/or 
computer(s)  to  the  home  communicator.  The  additional  television(s)  and 
telephone(s),  when  connected  to  the  home  communicator  will  receive  input 
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from  the  home  communicator.  The  additional  computer(s)  connected  will  be 
networked  with  the  home  communicator  upon  connection. 

High-level  quality  of  service  requirements  for  the  home  communicator  listed: 

•  Aesthetic  design:  The  home  communicator  must  be  a  contemporary  piece 

that  draws  the  customer  to  purchase  it  because  it  adds  beauty  and 
functionality  to  his  or  her  household. 

•  Reliable:  The  software  within  the  home  communicator  package  must  be  hearty 

enough  to  prevent  system  lock  up  and/or  crashes. 

•  Inexpensive:  The  home  communicator  should  be  inexpensive  to  the  middle 

and  low  class  clientele.  The  cost  should  be  between  100-200  dollars. 

•  Relatively  small:  The  home  communicator  must  be  small  enough  to  fit  in  any 

room  of  the  house.  The  home  communicator  will  have  a  15  inch  screen  and 
the  unit  will  be  all  inclusive  within  the  monitor  unit. 

•  Self-explanatory  setup:  The  communicator  must  be  self-explanatory  to 

customers  throughout  the  installation,  setup,  and  overall  operation  process. 

•  Easy  to  increase  functionality:  The  customer  must  be  able  to  add  new 

televisions  or  telephones  to  the  home  communicator  on  their  own. 

•  Intuitively  obvious  to  operate:  The  communicator  must  be  easy  to 

understand  for  the  most  computer  illiterate  customers. 

•  Robust  for  continuous  operation:  The  home  communicator  must  withstand 

24  hour,  7  day  per  week  continuous  utilization. 

•  Superior  functionality:  It  is  important  that  all  the  functions  be  available  at  all 

times.  If  someone  is  using  the  telephone  it  is  important  that  the  television 
service  is  not  interrupted. 

•  5-year  life  span:  It  is  important  that  a  home  communicators  sold  today  last  for 

at  least  five  years  within  the  customer’s  household  with  no  requirement  for 
repair  or  upgrade. 

B.  INDIVIDUAL  FUNCTIONAL  SPECIFICATIONS 

•  Television:  The  home  communicator  will  supply  the  capability  for  customers  to 

watch  television  on  the  communicator  screen  as  an  individual  software 
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application.  This  television  software  application  or  television  panel  can  be 
sized  to  encompass  the  entire  screen  or  sized  smaller  and  placed  on  the 
functional  desktop  in  order  to  utilize  other  computer  functions  on  the  home 
communicator  while  displaying  the  television  application. 

•  Telephone:  The  home  communicator  will  have  built  in  telephony  capability.  A 

telephone  software  application  will  allow  the  customer  to  place  a  call  or 
accept  an  incoming  call  by  using  the  trackball  mouse  and  screen  selection. 
The  telephone  can  be  used  while  operating  other  computer  functions  on  the 
home  communicator.  The  home  communicator  will  have  a  built  in 
microphone  and  speaker  in  order  to  utilize  the  telephony  capability  from  the 
home  communicator. 

•  Web  Browser:  The  web  browser  capability  will  allow  access  to  the  World  Wide 

Web  from  the  home  communicator.  Customers  will  be  able  to  view  the  web 
on  the  home  communicator  screen  without  interrupting  service  to  the 
television  or  telephone.  The  customer  will  have  a  keyboard  and  trackball 
mouse  input  in  order  to  utilize  this  web  browsing  function.  The  following  three 
specifications  for  e-mail,  chat,  and  text  editor  will  utilize  the  same  viewing 
screen,  keyboard,  and  trackball  mouse. 

•  E-Mail:  E-mail  will  be  available  to  the  customer  through  the  home 

communicator.  E-mail  will  be  displayed  on  the  screen  and  manipulated  by 
using  the  keyboard  and  trackball  mouse.  There  will  be  a  tone  associated  with 
each  incoming  e-mail  while  the  customer  has  the  e-mail  system  active.  The 
e-mail  program  will  be  relatively  simple  for  the  customer  to  learn  and  use. 

The  e-mail  service  will  be  part  of  the  ISP  package  of  the  home  communicator. 
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•  Chat:  Chat  capability  will  be  included  within  the  home  communicator  package 

to  allow  the  customer  to  contact  other  close  friends  or  relatives  on  line.  The 
chat  capability  allows  you  to  have  a  directory  of  persons  that  you  can  call  up 
quickly  by  using  an  on  line  message  exchange.  Instead  of  calling  and  talking 
to  someone  you  can  "chat"  by  first  determining  that  they  are  presently  on  line. 
Then  by  typing  a  sentence  or  so,  and  striking  the  enter  key  it  is  automatically 
sent  to  the  other  person  for  his/her  viewing  and  response. 

•  Text  Editor:  A  text  editor  will  be  included  in  the  capabilities  of  the  home 

communicator  to  assist  the  customer  with  document  and  e-mail  writing.  This 
will  operate  similar  to  a  word  processor  function. 

•  Connector  to  peripheral  equipment:  The  home  communicator  will  have 

connectors  that  allow  customers  to  attach  additional  telephone(s), 
television(s),  and  computer(s)  for  added  capability.  Once  plugged  into  the 
home  communicator  these  devices  will  operate  as  individual  items,  even 
though  they  will  be  networked  together  by  the  home  communicator, 
o  Television:  Each  peripheral  television  connected  to  the  home 

communicator  within  a  household  will  possess  the  capability  of  receiving 
all  available  channels  distinct  from  other  televisions  located  within  the 
household  including  the  home  communicator  itself.  Each  television  will 
have  a  number  pad  on  the  television  itself  or  on  a  television  remote  in 
order  to  turn  the  television  on  or  off  as  well  as  to  change  channels  or 
raise  or  lower  the  volume.  This  peripheral  television  service  will  operate 
independent  of  the  home  communicator  telephone  and  computer 
capability. 

o  Telephone:  Each  peripheral  telephone  within  the  household  will  possess 
the  capability  to  call  another  phone  within  the  household,  neighborhood, 
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or  even  long  distance  simply  by  utilizing  the  touch  number  pad  located  on 
the  phone.  The  peripheral  telephones  will  operate  just  as  standard 
telephones  operate.  There  is  no  requirement  that  the  other  end  have  a 
home  communicator;  the  system  will  be  joined  to  the  public  telephone 
service  for  customers  that  utilize  the  public  phone  system, 
o  Computer:  Each  peripheral  computer  within  the  household  will  be 
networked  upon  connection  to  the  home  communicator.  This  will  also 
allow  customers  to  connect  other  network  items  such  as  printers), 
facsimile  machine(s),  and/or  photo  copier(s)  in  addition  to  computers. 

C.  CUSTOMER  VIEW  OF  THE  HOME  COMMUNICATOR 

The  Home  Communicator  is  a  unique  product  that  combines  the  individual 
telephone  and  television  services  into  one  package  for  the  household  while  adding  a 
web  browsing,  e-mail,  chat,  and  text  editor  capability.  Section  A  described  the 
requirements  for  the  product.  Section  B  described  exactly  what  specific  capabilities 
must  be  available  within  the  home  communicator  for  the  customer.  This  section  will 
explain  precisely  what  the  customer  should  expect  to  receive  when  purchasing  the  home 
communicator  and  how  the  home  communicator  will  operate  within  the  household. 

The  home  communicator  is  a  one-piece  device.  Simply  put  the  home 
communicator  will  appear  as  a  monitor  with  a  keyboard,  speaker,  microphone,  and 
trackball  mouse  built  in.  Figure  4-1  displays  a  high-level  design  sketch  of  the  home 
communicator.  The  consumer  will  use  the  screen  and  keyboard  located  at  the  front  and 
the  trackball  mouse  located  on  the  right  side  of  the  home  communicator  to  control  the 
home  communicator  and  accomplish  web  browsing,  e-mail,  chat,  text  editor,  and  any 
other  computer  functions.  The  consumer  will  utilize  the  speaker  for  the  television  and 
the  speaker  and  microphone  for  telephone.  The  home  communicator  will  be  powered  by 
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standard  household  electricity.  There  will  be  a  small  microphone  and  speakers  located 
on  the  front  of  the  home  communicator  as  well  to  support  the  television  and  telephone 
requirement  of  the  home  communicator.  The  connector  for  the  electric  power  is  at  the 
rear  of  the  home  communicator.  The  connector  for  the  ISP  input  (optical  fiber)  is  located 
on  the  back  of  the  home  communicator.  Connectors  for  peripheral  television(s), 
telephone(s),  and  computer(s)  are  also  located  on  the  rear  of  the  home  communicator. 


computer  connectors 
television  connectors 

telephone  connectors 


Figure  4-1  Conceptual  Views  of  the  Communicator  Hub 

The  home  communicator  will  function  as  the  hub  of  a  home  computer  network. 
The  consumer  may  connect  any  peripheral  devices  they  possess  directly  to  the  home 
communicator  completing  the  household’s  computer  network.  These  peripheral  objects, 
telephones,  televisions,  and  computers,  only  need  to  be  standard  devices  that  can  be 
found  in  any  appliance  or  general  purpose  store.  Figure  4-2  displays  how  a  home 
communicator  system  can  operate  within  an  ordinary  household  with  peripheral 
telephones,  televisions,  and  computers. 
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Figure  4-2  Future  Household  with  Home  Communicator  and  Optical  Fiber  Network. 

This  home  has  one  home  communicator,  four  peripheral  telephones, 
three  peripheral  televisions,  and  two  peripheral  computers.  The 
kitchen  has  a  television  and  telephone  within  the  home  communicator. 
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The  home  communicator  screen  will  utilize  a  simple  GUI  for  the  customer’s 
convenience.  The  intent  is  to  offer  a  visual  selection  desktop  that  is  intuitive  to  any  non¬ 
computer  person.  The  consumer  can  select  a  requested  service  by  using  the  trackball 
mouse  on  the  side  of  the  home  communicator  to  place  the  arrow  over  the  icon  and  click 
to  open  the  application.  Another  method  that  can  be  utilized  to  activate  an  application 
will  be  buttons  on  the  upper  or  lower  Linux  KDE  panel.  The  functions  available  on  the 
home  communicator  are  web  browsing,  e-mail,  chat,  text  editor,  preference  selection  for 
peripheral  television(s)  and  telephone(s),  and  an  ability  to  access  any  peripheral 
computers  connected  through  the  home  communicator.  Figure  4-3  depicts  a  basic  view 
of  the  home  communicator  screen  displaying  possible  selection  options. 


Figure  4-3  Basic  view  of  the  communicator  hub  screen 
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D. 


SOFTWARE  HIGH  LEVEL  DESIGN 


The  functionality  of  the  home  communicator  cannot  be  accomplished  without  a 
complete  software  and  hardware  solution.  Linux  is  the  core  of  the  software  system  but 
without  certain  application  software  specific  requirements  will  not  be  met.  Since  the 
choice  has  been  made  to  use  Linux  for  the  operating  system  it  is  important  to  choose 
software  applications  that  are  fully  Linux  compatible.  KDE  desktop  environment  will  be 
the  overarching  Linux  GUI  and  desktop  solution. 

The  following  bullets  list  and  describe  the  software  selections  supporting  the 
functional  specifications: 

•  Television:  Requires  any  off-the-shelf  software  application  that  would  allow 

the  consumer  to  view  an  incoming  television  signal  within  a  computer 
panel. 

•  Telephone:  The  software  required  to  support  the  telephone  functionality  most 

likely  would  be  an  off-the-shelf  item  as  well.  The  telephone  software  may 
need  to  be  slightly  changed  to  support  the  exact  requirements  of  the  home 
communicator. 

•  Web  Browser:  The  web  browser  software  will  be  the  Linux  version  of 

Netscape.  The  KDE  desktop  and  lower  panel  will  be  set  up  with  Netscape 
icons  for  ease  of  customer  use. 

•  E-mail:  The  KDE  version  of  e-mail  (kmail)  will  be  utilized  to  supply  the  e-mail 

capability  on  the  home  communicator.  The  home  communicator  must  be 
on  7  days  per  week,  24  hours  a  day  therefore  the  home  communicator  will 
be  set  up  as  a  mail  server.  This  would  preclude  the  ISP  from  servicing  mail 
storage  servers  at  intermediate  locations.  Upon  initial  set  up  of  each  home 
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communicator  it  is  necessary  to  default  mail  storage  to  a  finite  time  frame  to 
prevent  memory  space  problems  on  the  home  communicator. 

•  Chat:  The  chat  functionality  (Chat  Client)  will  also  be  handled  through  the 

KDE  desktop  software.  Chat  functionality  will  also  be  loaded  with  Netscape 
(Instant  Messenger)  since  it  is  included  standard  with  the  Netscape  install. 
The  customer  will  be  able  to  choose  whichever  he  or  she  prefers  to  utilize. 

•  Simple  Text  Editor:  The  text  editor  functionality  is  another  function  that  is 

standard  within  the  KDE  Desktop  environment  (Text  Editor).  As  this 
functionality  is  quite  good  for  normal  requirements  this  will  suffice  for  the 
home  communicator.  Star  Office  is  another  possible  option  but  not 
recommended  as  its  space  and  RAM  requirements  will  only  create  a  need 
for  greater  hardware  requirements. 

•  Peripheral  devices  require  the  following  software: 

o  Television:  Requires  no  software  application  to  support  the  peripheral 
television  capability.  The  home  communicator  will  use  hardware  to 
supply  the  constant  television  signals  on  to  the  peripheral  televisions, 
o  Telephone:  The  software  required  to  support  the  peripheral  telephone 
functionality  most  likely  would  not  be  an  off-the-shelf  item.  Although 
voice  has  been  translated  to  IP  packets  with  software  such  as  Speak 
Freely,  there  is  an  additional  requirement  for  a  translator  function  within 
the  home  communicator  to  operate  a  standard  telephone  connected  to 
the  computer.  This  would  have  to  be  specifically  designed  from 
examination  of  existing  software  packages.  A  hardware  and  software 
solution  would  be  developed  during  the  design  phase  of  the  home 
communicator. 
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o  Computers:  The  operating  software  from  the  home  communicator  will 
support  access  to  peripheral  computers  from  the  home  communicator. 

E.  HARDWARE  HIGH  LEVEL  DESIGN 

The  hardware  design  will  operate  with  the  software  package  to  produce  a  highly 
reliable  multifunction  unit.  In  order  to  keep  cost  savings  a  priority  suggestions  to  use 
existing  off-the-shelf  hardware  elements  are  made  wherever  possible.  The  overall 
hardware  design  has  been  split  into  three  groups,  home  communicator,  telephone,  and 
television.  The  home  communicator  operates  as  the  brain  and  it  controls  the  overall 
functionality  of  the  home  network. 

The  actual  household  wiring  required  to  support  the  home  communicator  concept 
is  beyond  the  scope  of  this  thesis.  The  basic  assumption  is  that  the  optical  fiber 
provides  the  input  signal  for  the  home  communicator,  peripheral  computer(s),  peripheral 
television(s),  and  peripheral  telephone(s)  to  the  entire  house.  The  optical  fiber  connects 
directly  into  the  back  of  the  home  communicator.  All  of  the  peripheral  televisions  and 
telephones  located  within  the  house  connect  directly  to  the  back  of  the  home 
communicator  as  well.  The  peripheral  televisions  utilize  coaxial  cable,  the  peripheral 
telephones  use  the  standard  4-wire  telephone  cable,  and  the  peripheral  computer  use 
standard  twisted  pair  cable.  The  individual  hardware  item  descriptions  within  this  section 
have  not  been  verified  for  actual  cost  and  capability.  These  descriptions  are  included 
here  to  demonstrate  overall  feasibility  of  design  concept. 

1.  Home  Communicator 

The  home  communicator  controls  the  overall  home  network  system.  The  home 
communicator  will  be  a  complete  package  that  houses  the  monitor,  CPU,  keyboard,  and 
mouse  trackball  all  within  one  unit.  Figure  4-1  illustrates  several  conceptual  views  of 
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such  a  home  communicator.  The  hardware  within  the  home  communicator  may  include 
an  Intel  processor  Pentium  series  whichever  is  readily  available  at  the  time  of 
development.  The  hard  drive  for  the  hub  will  be  at  least  500  Meg  or  larger  depending  on 
availability  and  cost.  The  Linux  kernel  will  boot  and  run  off  of  read  only  flash  memory. 
This  will  protect  the  setup  from  possible  administrative  mistakes  by  the  customer  and 
memory  leaks  that  happen  over  time  with  all  GUI  operating  systems.  The  hard  drive  will 
be  for  consumer  mail  and  file  storage.  There  will  be  at  least  32  MB  RAM  in  order  to 
support  the  KDE  desktop  environment  memory  requirements.  The  keyboard  and 
trackball  mouse  will  be  designed  and  manufactured  specifically  for  this  purpose.  This 
unit  will  be  loaded  and  configured  with  the  Linux  operating  system  described  in  the 
second  chapter.  The  home  communicator  will  be  all  encompassing  with  coaxial  plugs  (F 
connectors),  telephone  plugs  (RJ-1 1 ),  and  computer  plugs  (RJ-45)  on  the  back  for  ease 
of  hookup  and  television  and  telephone  connection.  The  input  to  the  home 
communicator  will  be  an  optical  fiber  plug  (ST  Connector)  located  on  the  rear  of  the 
home  communicator.  Figure  4-1  demonstrates  these  input  and  output  plugs  at  the  rear 
of  the  home  communicator  unit. 

2.  Peripheral  Telephone 

The  standard  telephones  required  to  support  the  peripheral  telephone  capability 
will  be  plugged  into  the  home  communicator  with  standard  4-strand  telephone  wire.  The 
telephone  wire  will  plug  into  a  standard  RJ-1 1  connector  located  at  the  back  of  the  home 
communicator.  There  will  be  several  phone  connections  possible  into  each  home 
communicator.  Figure  4-1  demonstrates  the  RJ-1 1  connectors  at  the  rear  of  the  home 
communicator. 

In  order  for  us  to  utilize  a  normal  telephone  connected  to  the  communicator  there 
is  a  necessity  to  develop  a  software  and  hardware  solution  that  will  manage  the  unique 
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requirements  of  IP  telephony  and  standard  voice  over  wire  through  a  standard 
telephone.  The  software  must  address  dial  up,  connection  procedures  and  conversion 
of  incoming  IP  packets  to  voice  and  vice  versa.  The  hardware  must  support  the 
telephone  RJ-1 1  connector  in  conjunction  with  a  NIC  card  functionality  to  support  the 
specifications  for  the  home  communicator  telephone.  Each  telephone  will  plug  into  an 
individual  “telephone  NIC  card”  to  support  distinct  IP  addresses  for  each  peripheral 
telephone.  Individual  IP  addresses  prevent  the  requirement  to  incorporate  expensive 
off-the-shelf  IP  telephone  technology.  Each  telephone  to  the  house  would  maintain  the 
capability  to  call  any  other  phone  within  the  house  or  outside  the  household. 

3.  Peripheral  Television 

The  peripheral  television  will  be  a  basic  analog  television.  The  only  requirement 
for  the  television  is  that  it  must  have  a  coaxial  connection  for  a  cable  input  that  will 
connect  the  home  communicator  to  the  television.  The  coaxial  cable  will  be  connected 
to  the  standard  F  connector  at  the  back  of  the  home  communicator.  The  coaxial 
requirement  is  utilized  in  order  to  draw  upon  presently  available  technology.  The 
television  signal  input  into  the  home  communicator  will  be  the  same  signal  that  is 
presently  utilized  by  cable  television  companies.  The  signal  will  be  continuously  sent  on 
a  different  fiber  optic  channel  from  the  ISP,  possibly  utilizing  WDM  described  in  Chapter 
1 B  of  this  thesis.  The  home  communicator  hardware  will  automatically  decrypt  the 
separate  channel  as  a  television  signal  and  pass  the  signal  directly  on  through  to  the 
television(s).  The  home  communicator  will  have  several  coaxial  connections  to  connect 
several  customer  televisions  from  each  home  communicator.  The  customer  will  control 
the  television  by  using  the  controls  on  the  television  or  a  television  remote.  Figure  4-1 
demonstrates  the  F  connectors  at  the  rear  of  the  home  communicator. 
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4.  Peripheral  Computers 

Any  standard  computers  that  the  customer  possesses  can  be  connected  directly 
to  the  home  communicator  through  the  RJ-45  plugs  located  on  the  rear  of  the  home 
communicator.  Each  RJ-45  connector  within  the  home  communicator  will  incorporate  a 
NIC  card  to  initiate  the  interface  between  the  home  communicator  and  peripheral 
computer.  Each  consumer  peripheral  computer  must  have  a  NIC  card  to  facilitate  the 
connection  as  well. 
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V.  PLAN  OF  EXECUTION  FOR  SIX  MONTHS 


The  plan  of  execution  for  the  home  communicator  will  be  broken  down  into 
several  aspects  of  development.  The  first  aspect  described  here  will  be  a  list  and 
description  of  individual  tasks  required  for  the  three  major  phases  of  development: 
software/hardware  design,  prototype,  and  production.  The  second  aspect  described 
here  is  the  overall  team  strategy  and  the  personnel  requirements  to  support  the  team 
strategy.  This  includes  both  the  quantity  of  personnel  required  to  staff  the  teams  and  the 
specific  skills  necessary  to  accomplish  the  required  tasks.  A  third  aspect  is  the  time  line 
breakdown.  Although  this  plan  of  execution  does  not  include  actual  hardware 
development  it  will  be  assumed  into  the  prototype  and  production  phases. 

A.  DESCRIPTION  OF  REQUIRED  TASKS 

Table  5-1  displays  a  list  of  basic  tasks  required  to  develop  the  home 
communicator.  The  three  phases  overlap  but  also  maintain  an  independence  from  each 
other.  The  hardware/software  design  phase  includes  the  final  selection  of  software  and 
hardware  and  the  design  development  leading  to  the  prototype  phase.  The  prototype 
phase  is  the  actual  production  of  a  first  unit  and  the  time  frame  included  to  test  and 
evaluate  the  design.  Any  changes  to  the  design  software  or  hardware  made  before  final 
production  fall  under  the  prototype  phase.  The  production  phase  portrays  the  time  frame 
after  the  first  product  is  sold  and  represents  tasks  that  will  be  required  throughout  the  life 
span  of  the  product. 

The  first  two  necessities  in  the  design  phase  are  the  requirements  documentation 
and  the  configuration  control  plan.  These  both  are  crucial  for  the  development  of  the 
home  communicator.  The  requirements  document  establishes  the  target  goal  of  the 
home  communicator.  It  maintains  the  vision  of  the  final  product  and  will  not  change 
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unless  requirements  cannot  be  met  as  originally  planned.  The  configuration  control  plan 
must  be  developed  prior  to  or  at  the  latest  in  conjunction  with  the  requirements 
documentation.  The  configuration  control  plan  will  establish  how  configuration  control  is 
to  be  maintained  throughout  the  development  of  the  home  communicator.  It  will 
describe  specific  information  that  is  required  to  baseline  requirements  and  the 


hardware/software  design  packages. 


Design  Phase 


Prototype  Phase 


requirements 
documentation 
configuration  control 
plan 

finalize  telephony 
design 

finalize  e-mail  design 
initial  hardware/software 
specifications 
document 

software  modification  for 
IPv6  Implementation 
software  development 
for  telephony 


purchase  hardware 
setup  hardware 
integration  testing 
modify  design 


Production  Phase 

develop  documentation 
for  customer 
develop  final 
specifications 
documentation 
purchase/lease  control 
centers  for  ISP 
set  up  help  desk 
modify  design  for 
obsoleted  items 


Table  5-1  Tasks  required  for  development  of  the  home  communicator  by  phases 

The  next  requirement  for  the  design  phase  is  the  selection  of  the  telephony  and 


e-mail  strategy.  Because  these  two  capabilities  can  be  handled  in  any  of  several  ways 
to  support  the  requirements  document  it  is  important  to  make  high  level  design  decisions 
prior  to  the  finalization  of  the  initial  hardware/software  specifications  document.  After  the 


product  design  (telephony  and  e-mail)  is  finalized  decisions  will  be  documented  within 
the  initial  specifications  document.  The  initial  hardware/software  specifications 


document  will  detail  hardware  and  software  modifications  and  extensions  required  to 


produce  the  home  communicator.  The  modification  of  Linux  and  application  software 
will  then  be  undertaken. 


At  the  same  time  the  modifications  and  development  of  the  software  packages 
are  taking  place  the  prototype  phase  begins  with  the  purchase  of  the  hardware.  During 
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the  beginning  of  this  phase  hardware  engineers  are  purchasing  material  and  building  the 
prototype  hardware  package.  After  the  setup  of  hardware  integration  testing  will  be 
accomplished  to  test  the  feasibility  of  design.  If  any  problems  arise  the  design  will  be 
modified  and  retested.  Any  major  changes  required  due  to  serious  testing  failure  will 
require  a  revisit  to  the  design  phase  in  order  to  evaluate  the  problem  and  redesign  the 
prototype. 

The  production  phase  begins  during  the  secondary  stages  of  the  prototype 
phase.  Customer  documentation  development  is  begun  at  the  onset  of  integration 
testing  if  not  sooner.  In  addition  to  customer  documentation  the  upkeep  of  the 
requirements  and  configuration  documentation  described  above  is  undertaken  during  the 
production  phase.  The  final  specifications  documentation  is  undertaken  after  a 
successful  prototype  system  is  completed.  Also  during  this  phase  a  help  desk  is  stood 
up  for  customer  support.  Any  ISP  required  facilities  will  be  established  during  this  phase 
as  well.  Finally,  there  is  an  ongoing  requirement  to  monitor  for  obsolete  production 
items  that  begins  during  the  production  phase. 

B.  TEAM  STRATEGY  AND  PERSONNEL  REQUIREMENTS  WITHIN  THE 

TEAMS  TO  ACCOMPLISH  TASKING 

The  overall  project  will  consist  of  task-oriented  teams.  There  will  be  a  total  of  five 
teams:  hardware,  software,  documentation,  prototype,  and  production.  Generally,  the 
software  team  will  be  responsible  for  development  of  the  Linux  operating  system  and 
application  support  package.  The  hardware  team  will  be  responsible  for  selection  of 
Linux  compatible  hardware  that  supports  the  home  communicator  specifications.  The 
documentation  team  will  handle  the  requirements,  configuration  control,  specifications, 
and  customer  documentation.  The  prototype  team  will  control  all  aspects  of  the 
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prototype  process.  The  production  team  will  be  responsible  for  all  items  of  maintenance 
occurring  after  the  prototype  phase. 

Prior  to  the  development  of  the  home  communicator  the  hardware  and  software 
team  will  together  be  responsible  for  the  major  design  decisions  at  the  same  time  the 
documentation  team  is  responsible  for  documenting  the  major  design  decisions.  The 
prototype  team  will  develop  the  prototype  and  report  testing  results  back  to  the  initial 
hardware  and  software  teams.  The  prototype  team  will  consist  of  select  members  from 
the  software  and  hardware  teams  as  well  as  a  single  software  test  engineer.  This 
software  test  engineer  will  be  involved  at  the  beginning  of  the  project  only  as  an  impartial 
consultant;  he/she  is  to  remain  separate  from  the  design  phase  itself.  This  is  necessary 
in  order  to  maintain  a  level  of  neutrality  to  the  design  during  prototype  testing. 

Any  major  problems  arising  during  the  prototyping  phase  from  hardware  and 
software  incompatibility  will  be  resolved  through  a  coordinated  effort  from  the  software, 
hardware,  and  prototype  teams.  The  documentation  team  will  develop  first  the 
requirements  and  design  documentation  and  later  during  the  prototype  and  production 
phase  the  customer  documentation.  The  documentation  team  will  include  select 
hardware  and  software  team  members  to  assist  with  the  establishment  of  the  home 
communicator  requirements. 

The  production  team  takes  over  from  the  hardware  and  software  teams  after  the 
successful  test  and  evaluation  of  the  home  communicator  prototype.  The  production 
team  is  made  up  of  hardware,  software,  prototype,  and  documentation  personnel.  The 
production  team  will  become  the  customer  help  desk.  The  production  personnel  will  also 
continue  to  design  changes  to  the  home  communicator  as  obsolescence  problems  arise. 
The  production  personnel  will  assist  with  high-level  requirements  such  as  design  and 
deployment  of  any  internet  service  provider  stations  required. 
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The  general  experience  required  for  all  team  personnel  to  complete  the  tasking 
includes  Linux  operating  system,  computer  networking  (TCP/IP),  e-mail  administration, 
computer  hardware  familiarity,  and  Linux  software  programming.  The  personnel 
required  for  all  the  individual  teams  must  have  an  expert  level  of  experience  in  at  least 
one  or  more  of  these  categories  to  support  the  project. 

In  order  to  set  up  the  five  teams  as  described  all  persons  hired  are  by  necessity 
required  to  have  several  talents.  The  teams  will  each  consist  of  anywhere  from  4  to  6 
members,  but  as  stated  above  most  of  the  personnel  will  be  on  more  than  one  team.  At 
least  two  team  members  for  the  hardware  and  software  teams  must  also  become  part  of 
the  prototype  team.  At  least  one  of  the  hardware  and  software  team  members  must  also 
become  part  of  the  documentation  team.  The  documentation  team  will  consist  of  4 
members  only.  The  other  two  of  the  members  will  remain  on  the  documentation  team 
only  and  only  assist  other  teams  if  imperative.  The  members  hired  for  the  hardware  and 
software  teams  will  either  direct  themselves  into  the  documentation  or  prototyping  arena 
when  not  directly  focused  on  the  planning  and  design  sessions.  This  practice  will  help 
maintain  a  natural  level  of  task  management  within  the  company.  Also,  this  practice 
promotes  the  employees  a  high  level  of  information  sharing  throughout  the  process. 

Approximately  fifteen  personnel  must  be  hired  to  support  this  type  business 
structure.  When  hiring  the  individual  team  members  it  is  important  to  choose  hardware 
personnel  that  possess  a  strong  background  and  interest  in  technical  writing  (1  or  2 
personnel)  or  test  engineering  (1  or  2  personnel).  The  test  engineering  experience  will 
directly  support  the  prototype  phase.  The  software  personnel  hired  must  also  possess  a 
strong  background  and  interest  in  technical  writing  (1  or  2  personnel)  or  test  engineering 
(1  or  2  personnel).  It  is  also  important  that  at  least  one  hardware  person  has  formidable 
experience  with  Linux  software.  The  leaders  of  each  group  will  be  chosen  from  their 
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level  of  knowledge  and  management  experience.  The  software  test  engineer  must  have 
specific  manufacturing  experience  from  a  hardware  and  software  standpoint. 

C.  TIMELINE  OF  6  MONTH  EXECUTION 

Figure  5-1  displays  the  estimated  timeline  for  the  project.  The  start  dates  are 
given  as  weeks  from  the  initial  start  of  the  project.  The  time  frame  column  describes  the 
amount  of  time  the  evolution  is  projected  to  take  with  all  team  members  present. 
Although  the  dates  are  given  as  factual  it  must  be  understood  that  flexibility  would  be 
important  for  such  an  undertaking.  There  is  no  way  to  anticipate  hardware  and  software 


incompatibilities  prior  to  the  actual  prototype  phase. 


TASK 

start  date 

end  date 

time  frame 

Design  Phase 

wk  1 

wk  16 

16  wks 

requirements  document 

wk  1 

wk3 

2  wks 

configuration  control  plan 

wk  1 

wk  3 

2  wks 

choose  telephony  design 

wk  3 

wk  5 

2  wks 

choose  e-mail  design 

wk  3 

wk  5 

2  wks 

initial  hardware/software  specifications  document 

wk3 

wk  8 

5  wks 

software  modification  for  IPv6  Implementation 

wk  8 

wk  16 

8  wks 

software  design  for  telephony 

wk  8 

wk  16 

8  wks 

Prototype  Phase 

wk  8 

wk26 

18  wks 

purchase  hardware 

wk  8 

wk  14 

6  wks 

set  up  hardware 

wk  14 

wk  16 

2  wks 

integration  testing 

wk  16 

wk  20 

4  wks 

modify  design 

wk  20 

wk  26 

6  wks 

Production  Phase 

wk  8 

wk  26 

18  wks 

develop  documentation  for  customer 

wk  8 

wk  26 

18  wks 

develop  final  specifications  documentation 

wk  8 

wk  26 

18  wks 

purchase/lease  control  centers  for  ISP 

wk  8 

wk26 

18  wks 

set  up  help  desk 

wk  14 

wk  26 

12  wks 

modify  design  for  obsoleted  items 

- 

indef. 

Figure  5-1  Estimated  Timeline  for  Home  Communicator  Development 
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VI.  CONCLUSIONS 


Previously  all  household  communication  and  entertainment  services  have  been 
viewed  as  separate  items.  These  include  television,  telephone,  and  computer  internet 
services.  As  computer  capability  continues  to  grow  a  transformation  from  separate 
services  will  migrate  into  one  service.  This  service  operating  within  a  networked 
household  will  present  television,  telephone,  web  browsing,  and  computer  functionality 
all  from  the  one  incoming  signal. 

This  thesis  has  shown  that  overall  software  presently  exists,  specifically  Linux 
operating  software  that  could  successfully  manage  such  a  communications  hub.  This 
communications  hub  would  be  capable  of  interpreting  a  single  ISP  input  to  direct  the 
individual  services  to  the  proper  device.  Additional  functionality  could  easily  be  included 
through  Linux  compatible  applications  offering  the  customer  a  simple  to  operate,  stable 
electronic  mechanism.  Individual  functions  offered  would  include  television,  telephone, 
internet  web  browser,  chat,  and  simple  text  editor.  In  order  to  accomplish  this  concept, 
though,  there  are  several  major  issues  to  address. 

The  use  of  IP  telephony  poses  an  unusual  problem  to  the  home  communicator. 

It  cannot  be  solved  easily  through  the  home  communicator  design.  Software  packages 
presently  available  offer  computer-to-computer  functionality  or  computer  to  telephone 
functionality.  Present  technology  requires  that  in  order  to  reach  existing  telephone 
service  customers  as  well  as  other  home  communicator  customers  it  is  necessary  to 
develop  a  gateway  architecture  system  connecting  into  the  existing  telephone  system. 
The  ISP  must  accomplish  this.  A  final  option  outside  the  scope  of  this  thesis  would  be  to 
design  the  home  communicator  as  a  server  that  supported  direct  IP  telephony  through 
extensive  software  design. 
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Another  problem  area  discovered  was  the  e-mail  capability  of  the  home 
communicator.  In  order  to  support  e-mail  clients  the  requirement  for  mail  server  storage 
would  be  shifted  to  the  ISP.  Mail  server  storage  would  have  to  be  supported  either 
through  the  IPS  or  another  service.  An  option  outside  the  scope  of  this  thesis  was  the 
design  of  the  home  communicator  to  be  a  mail  server  as  well  as  the  mail  client.  This 
would  not  be  a  helpful  design  considering  the  increased  level  of  processing  required  on 
the  home  communicator.  This  additional  server  software  could  easily  make  the 
communicator  too  complicated.  This  would  be  a  detriment  since  the  home 
communicator  is  to  be  marketed  as  an  easy  to  use  mechanism. 

IPv6  was  investigated  for  feasibility  with  the  home  communicator  and  found  to  be 
acceptable  as  the  internet  protocol  for  such  a  home  communicator.  IPv6  proposes  less 
overhead  processing  by  utilizing  a  smaller  header  and  a  different  procedure  for  handling 
packets  along  the  datagram  path.  IPv6  offers  several  new  header  fields  including  traffic 
class  and  flow  label  that  enhance  the  IP  telephony  and  large  data  transfer  requirements 
such  as  with  video  teleconferencing.  Although  IPv6  is  not  utilized  in  the  main  stream  of 
the  internet  yet  there  is  a  strong  push  to  progress  towards  it  before  2010  when  the  IPv4 
addresses  run  out.  Also,  new  versions  of  the  Linux  kernel  support  various  aspects  of 
IPv6  already.  Utilization  of  IPv6  now  with  ISP  IPv6  server  support  will  prevent  a  later 
requirement  to  upgrade  home  communicator  software  for  internet  protocol. 

Linux  has  proven  itself  a  very  stable  operating  system  with  very  few  functional 
problems.  It  must  be  noted  though  that  Linux  has  its  own  drawbacks.  Linux  displays  a 
problem  with  memory  leaks.  Although  the  problem  is  not  as  pronounced  as  found  with 
Microsoft  problems  leaving  a  Linux  computer  on  24  hours  per  day  7  days  per  week  as 
required  with  the  home  communicator  will  eventually  create  a  system  lock  up  due  to 
memory  leaks.  Therefore,  it  is  important  that  the  home  communicator  owner  must 
systematically  reboot  his  or  her  machine  in  order  to  clear  the  system  of  memory  leaks 
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before  it  creates  a  system  crash.  Utilization  of  a  flash  memory  for  the  system  boot  up 
disk  space  would  assist  with  this,  especially  after  system  crashes.  The  flash  memory 
cannot  be  written  to,  so  even  if  the  owner  crashed  the  system  with  his  or  her  lack  of 
knowledge  the  machine  would  still  boot  up  clean  every  time.  This  problem  leaves  a 
potential  black  mark  on  the  home  communicator.  No  one  ever  has  to  reboot  their 
present  day  telephone  due  to  a  memory  leak  or  any  other  reason.  Finally,  it  must  be 
noted  that  even  though  Linux  can  be  delivered  to  the  customer  configured  it  will  never  be 
completely  intuitive  to  persons  who  have  never  seen  a  computer  screen  or  those  that 
are  familiar  with  Microsoft  operating  systems.  There  will  be  a  learning  curve  and  a  help 
desk  will  be  required  by  the  ISP  to  answer  these  basic  first  time  questions. 

Computer  technology  has  approached  a  level  that  can  accommodate  the  home 
communicator  system  described  here.  As  seen  major  decisions  must  be  addressed  and 
supported  by  the  ISP  in  order  to  support  all  the  functionality  though.  As  technology 
continues  to  expand  the  world  market  this  home  communicator  concept  will  become 
more  prevalent. 
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